using DirectX/DirectWrite for rendering text.

[Taro MURAOKA]

Hi, list and Bram.

Using modern fonts on MS-Windows, some texts drawn by GDI are very
nasty. See attached before-dirextx.png, it is that. Ken Takata and I
are working on this problem for the past few weeks, and have completed a
patch to resolve it. Attached patch-direct_write.diff is that.

In this patch, we use DirectX (DirectWrite) to draw texts. We
implemented it with dynamic loading, so it make disabled automatically
on MS-Windows old version which doesn't support DirectWrite (ex: XP).

See after-directx.png, it have more beautiful rendered glyph than
before-directx.png.

I hope this patch helps complex glyph users, not only Japanese.

[Christian Brabandt]

Hi Taro!

Thanks, that sounds interesting. Is there a reason, we need a special
option just for Windows or can't we always use directx, if it is
available?

regards,
Christian
--
Seit fr�her Kindheit, wo man froh lacht, verfolgt mich dieser
Ausspruch magisch: Man nehme ernst nur das, was froh macht, das Ernste
aber niemals tragisch!
-- Heinz Erhardt

[MURAOKA Taro]

Because of compatibility and drawing speed.

It is known that DirectWrite is slower than GDI on some environmemt.

Hi Taro!

On Do, 24 Jan 2013, Taro MURAOKA wrote:

> Hi, list and Bram.
>
>
> Using modern fonts on MS-Windows, some texts drawn by GDI are very
> nasty.  See attached before-dirextx.png, it is that.  Ken Takata and I
> are working on this problem for the past few weeks, and have completed a
> patch to resolve it.  Attached patch-direct_write.diff is that.
>
> In this patch, we use DirectX (DirectWrite) to draw texts.  We
> implemented it with dynamic loading, so it make disabled automatically
> on MS-Windows old version which doesn't support DirectWrite (ex: XP).
>
> See after-directx.png, it have more beautiful rendered glyph than
> before-directx.png.
>
>
> I hope this patch helps complex glyph users, not only Japanese.

Thanks, that sounds interesting. Is there a reason, we need a special
option just for Windows or can't we always use directx, if it is
available?

regards,
Christian
--

Seit früher Kindheit, wo man froh lacht, verfolgt mich dieser

Ausspruch magisch: Man nehme ernst nur das, was froh macht, das Ernste
aber niemals tragisch!
                -- Heinz Erhardt

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

[Ingo Karkat]

On 25-Jan-13 03:49:21 +0100, MURAOKA Taro wrote:

> Because of compatibility and drawing speed.
>
> It is known that DirectWrite is slower than GDI on some environmemt.

> [...]

> Thanks, that sounds interesting. Is there a reason, we need a special
> option just for Windows or can't we always use directx, if it is
> available?

+1 for making that configurable. I don't like font smoothing in Vim, and if
there's a risk that this switch introduces it, I'd like to have a means to turn
it off. However, I would prefer to avoid a separate (and Windows-only)
configuration option, imagining that in the future, there will likely be similar
rendering-related options, and that these unnecessarily pollute the namespace of
`:set` commands.

How about making "directx" a (first) value of a new generic 'guirender' option?!
Instead of
:set directx
make it
:set guirender+=directx`

This option:
- has a name that clearly conveys its purpose
- makes sense on all platforms
- allows for future extensions and (comma-separated) alternatives in a familiar
and proven syntax

-- regards, ingo

PS: Do not top-post! Type your reply below the text you are replying to.

[mattn]

> :set guirender+=directx

Why += ?

[Ingo Karkat]

On 25-Jan-13 10:21:49 +0100, mattn wrote:

>> :set guirender+=directx
>
> Why += ?

Well, initially (as this is the first option value, and the option would be
empty by default), it doesn't matter, but in general it is recommended to only
add / remove to such options (other examples are 'guioptions', 'clipboard',
'complete'), as the default may change or is platform-dependent. I just wanted
to express that this option is one of those.

-- regards, ingo

[Taro MURAOKA]

Ingo, thank you interesting and commented.

> How about making "directx" a (first) value of a new generic 'guirender' option?!

It sounds good to make it generic.
But how about adding a new flag to 'guioptions'

Like this:
:set guioptions +=X

When writing this patch, I was in two mind about it,
between creating a new option and adding a new flag to 'guioptions'.

Best.

[mattn]

> Well, initially (as this is the first option value, and the option would be
>
> empty by default), it doesn't matter, but in general it is recommended to only
>
> add / remove to such options (other examples are 'guioptions', 'clipboard',
>
> 'complete'), as the default may change or is platform-dependent. I just wanted
>
> to express that this option is one of those.

Ah, I understand.

[Mike Williams]

It improves text rendering for plain ol' ASCII as well - character stem
widths are more consistent. The effect is subtle with Consolas but more
obvious with Adobe's Source Code Pro - in fact, it makes Source Code Pro
look right (see attached)! Obviously Consolas was designed for use with
the default Windows fonts renderer so this patch improves rendering with
non MS fonts.

However, the patch does not work with bitmap fonts such as Courier - all
the text just disappears. The code needs to check the font format to
decide whether to use DirectX for font rendering.

TTFN

Mike
--
The two most common things in the Universe are Hydrogen and stupidity.

[Ingo Karkat]

On 25-Jan-13 11:31:26 +0100, Taro MURAOKA wrote:

> Ingo, thank you interesting and commented.
>
>> How about making "directx" a (first) value of a new generic
>> 'guirender' option?!
>
> It sounds good to make it generic.

Definitely. Since people will enable this once in .vimrc, it also doesn't matter
that it's slightly more obscure and longer to type than :set directx.

> But how about adding a new flag to 'guioptions'
>
> Like this:
> :set guioptions +=X
>
> When writing this patch, I was in two mind about it,
> between creating a new option and adding a new flag to 'guioptions'.

Looking at the existing values of 'guioptions', they are all about what the GUI
is composed off: menu, scrollbars, icons. I see the DirectX-functionality on
another (meta-)layer, because it influences how all the GUI components are
drawn, not what to include in the drawing. Also, that option is already pretty
cluttered. But if others would prefer that instead, I would not object; it's
still better than a new 'directx' option.

-- regards, ingo

[Taro MURAOKA]

Mike, thank you for reporting!

> However, the patch does not work with bitmap fonts such as Courier - all
> the text just disappears. The code needs to check the font format to
> decide whether to use DirectX for font rendering.

Please tell me your 'guifont' setting, about this.

[Mike Williams]

set guifont=Courier:h10:cANSI

This is on Windows 7 x64 Professional.

[Taro MURAOKA]

Thanks!

> set guifont=Courier:h10:cANSI
>
> This is on Windows 7 x64 Professional.

I can reproduce it, will investigate.

[Mike Williams]

On 25/01/2013 11:07, Mike Williams wrote:
> On 24/01/2013 14:43, Taro MURAOKA wrote:
>> I hope this patch helps complex glyph users, not only Japanese.
>
> It improves text rendering for plain ol' ASCII as well - character stem
> widths are more consistent. The effect is subtle with Consolas but more
> obvious with Adobe's Source Code Pro - in fact, it makes Source Code Pro
> look right (see attached)! Obviously Consolas was designed for use with
> the default Windows fonts renderer so this patch improves rendering with
> non MS fonts.

Other free monospace fonts like Inconsolata(*) and Anonymous Pro are now
usable on Windows as well. This is a good feature to add to VIM for all
Windows users that can use DirectX.

(*) There are problems with Inconsolata sizes 9 and 11, the equals sign
is rendered with only one line, but that most likely will be an issue
with the font program, not the DirectX font renderer.

[MURAOKA Taro]

Hi Mike.

> However, the patch does not work with bitmap fonts such as Courier - all
> the text just disappears. The code needs to check the font format to
> decide whether to use DirectX for font rendering.

Try this additional patch.
It checks is the font TTF or not, when it is not TTF,
fallback to GDI drawing.

Thanks.

2013/1/25 Mike Williams <mike.w...@globalgraphics.com>:

--
MURAOKA Taro <koron....@gmail.com>

[Mike Williams]

On 25/01/2013 12:56, MURAOKA Taro wrote:
> Hi Mike.
>
>> However, the patch does not work with bitmap fonts such as Courier - all
>> the text just disappears. The code needs to check the font format to
>> decide whether to use DirectX for font rendering.
>
> Try this additional patch.
> It checks is the font TTF or not, when it is not TTF,
> fallback to GDI drawing.

The patch prevents DirectX rendering for OpenType fonts, which
Inconsolata and Source Code Pro are - the value for tm.tmPitchAndFamily
for these fonts is 0x3a. It does fix the issue with Courier.

[MURAOKA Taro]

> The patch prevents DirectX rendering for OpenType fonts, which Inconsolata
> and Source Code Pro are - the value for tm.tmPitchAndFamily for these fonts
> is 0x3a.

Ah sorry, I forgot it.
Please try this revised one.
--
MURAOKA Taro <koron....@gmail.com>

[Mike Williams]

Yep, all working now. Thank you.

[Taro MURAOKA]

I have updated the patch. What are changed:

* support raster fonts.
* delay to load DirectX dlls until enabled first time.

What are not changed yet:

* make switching option generic.

[Mike Williams]

I have a build warning for you:

option.c(7943) : warning C4047: '==' : 'int *' differs in levels of
indirection from 'int **'

Unnecessary & on the following line?

else if ((int *)varp == &p_directx && p_directx)

HTH - TTFN

[Taro MURAOKA]

> I have a build warning for you

Thank you reporting it!

The definition of p_directx in options.h is wrong.
It was int pointer, must be int correctly.

I'll fix later.

[Taro MURAOKA]

Hi Ingo.

How about recycle an existing 'antialias' option for this purpose.
It is an option for MacOSX to control font rendering.
I know this is not good idea, but there is a platform depended option already.
Why can't we recycle it?

# 'antialias' maybe added by me so long ago, and I forgot it entirely ;)

[Bram Moolenaar]

If the effect of using DirectX is very similar to enabling antialias
then we could use that option. If it actually does something else then
it's better to use a different option.

--
A computer programmer is a device for turning requirements into
undocumented features. It runs on cola, pizza and Dilbert cartoons.
Bram Moolenaar

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Mike Williams]

On 26/01/2013 12:41, Bram Moolenaar wrote:
>
> Taro Muraoka wrote:
>
>> How about recycle an existing 'antialias' option for this purpose.
>> It is an option for MacOSX to control font rendering.
>> I know this is not good idea, but there is a platform depended option already.
>> Why can't we recycle it?
>>
>>
>> # 'antialias' maybe added by me so long ago, and I forgot it entirely ;)
>
> If the effect of using DirectX is very similar to enabling antialias
> then we could use that option. If it actually does something else then
> it's better to use a different option.

The DirectX DirectWrite text renderer is the new font renderer on
Windows. DirectWrite text rendering particularly improves OpenType
fonts which is why fonts such as Source Code Pro and Inconsolata with
western text also improve with this patch.

DirectWrite font rendering supports additional rendering options
analogous to those supported by freetype in X(*) - LED RGB order,
sub-pixel rendering, and anti-aliasing. These are set when configuring
ClearType from the font control panel applet, but they can also be set
for individual programs as well (it may be worth adding to any doc for
this patch that best results will be obtained with ClearType enabled and
configured). It is possible that DWriteContext_SetRenderingParams() in
the patch is meant to allow setting specific rendering options from a
multi-valued option or a collection of boolean ones.

(*) gdipp (http://code.google.com/p/gdipp/) is a project using freetype
to improve general Windows text rendering. This is an alternate to the
GDI renderer, not DirectX, so may still suffer from the GDI text API
limitations, I haven't tried it.

Mike
--
Just when they think they know the answers, I change the questions.

[Mike Williams]

On 25/01/2013 12:25, Mike Williams wrote:
> (*) There are problems with Inconsolata sizes 9 and 11, the equals sign
> is rendered with only one line, but that most likely will be an issue
> with the font program, not the DirectX font renderer.

For those interested, there is an improved version of Inconsolata (plus
a bold version) at the Google font directory:

http://code.google.com/p/googlefontdirectory/source/browse/ofl/inconsolata/

Mike
--
Thesaurus: Ancient reptile with an excellent vocabulary.

[Mike Williams]

Hi all,

Just wondering where this patch is up to. I have been using it for the
last 6 weeks without a problem here, using an Mercurial patch queue to
keep up to date with the main repo. Is something missing preventing it
going in?

TTFN

Mike
--
Thingamabob: a mechanical gadget of bizarre origin and unknown
applicability.

[MURAOKA Taro]

Hi MIke.

I will work on it and some other tasks ASAP.

2013/3/11 Mike Williams <mike.w...@globalgraphics.com>:

--
MURAOKA Taro <koron....@gmail.com>

[Taro MURAOKA]

Hi all!

At last, I have worked on this issue, and attached an updated patch.
Please check it.

To enable DirectWrite, you should set an option 'renderingoptions', like this:

:set renopt=type:directx

Now, this option can take some sub parameters, like this:

:set renopt=type:directx,gamma:1.4,geom:0,mode=3

Please check options.txt about detail of sub parameters.

If you want to see some repository of this patch, please see here:

https://bitbucket.org/koron/vim-kaoriya-vim-mq-ex/src/a4fb89fcfead2e48d959e94d339e44e5ebe76abe/patch-direct_write-r3.diff?at=default

Best regards.

[Taro MURAOKA]

I have updated the patch.

I have got a report from k-takata that previous one breaks cygwin build.

Please check this new version.

[Bram Moolenaar]

Thanks, that is a big piece of work.

I haven't looked at the code, but the option 'renderingoptions' could be
called 'renderoptions'. Just a bit easier to type. Also, the short
name isn't very short. How about 'rop'?

I hope a few people try it out and give feedback.


--
From "know your smileys":
8<}} Glasses, big nose, beard

[MURAOKA Taro]

> I haven't looked at the code, but the option 'renderingoptions' could be
> called 'renderoptions'. Just a bit easier to type. Also, the short
> name isn't very short. How about 'rop'?

I agreed totally, and have updated the patch about it.

* rename 'renderingoptions' to 'renderoptions'.
* rename 'renopt' to 'rop'.

Please check it.
--
MURAOKA Taro <koron....@gmail.com>

[Taro MURAOKA]

I have fixed a problem which ":set<CR>" is crash.

Best.

[Mike Williams]

On 26/03/2013 12:20, Taro MURAOKA wrote:
> I have fixed a problem which ":set<CR>" is crash.
>
>
> Best.
>

Looking good here, although I only use it for latin character sets.
Makes Source Code Pro font usable but has little effect on most Windows
fonts since they are designed for the GDI renderer's behaviour.

One thing that is not controllable is the type of anti-aliasing
performed - there needs to be a call to SetTextAntialiasMode() to
specify if grayscale or ClearType anti-aliasing should be done. Perhaps
this could be option aamode taking 0-3 as
perhttp://msdn.microsoft.com/en-gb/library/windows/desktop/dd368170%28v=vs.85%29.aspx
To avoid confusion how about renaming the mode option as geom (since
it relates to geometry of rgb components of a pixel) and geom as
positioning as it affects character layout.

It may be useful to document at least the modes.

For geom (what was mode):
0 - RGB components coincident (CRT displays)
1 - Pixel components in RGB order (most LCD displays)
2 - Pixel components in BGR order

For positioning (what was geom):
0 - Automatic rendering based on font and size.
1 - No anti-aliasing.
2 - Horizontal anti-aliasing with GDI Cleartype character positioning.
3 - Horizontal anti-aliasing with improved GDI Cleartype positioning.
4 - Horizontal anti-aliasing with natural positioning.
5 - Horizontal and vertical anti-aliasing with natural positioning.
6 - Use font outlines directly

For aamode (if implemented):
0 - System default.
1 - ClearType anti-aliasing.
2 - Grayscale anti-aliasing.
3 - No anti-aliasing.

HTH - TTFN

Mike
--

Confession is good for the soul, but bad for your career.

[Taro MURAOKA]

I updated the patch which attached. I have changed these:

* Add document which describe enum values.
* Rename "mode" to "renmode".
* Add "taamode" for text antialising mode.

> there needs to be a call to SetTextAntialiasMode() to specify if
> grayscale or ClearType anti-aliasing should be done.

I have implemented this. But I don't know is it correct or not. If it
is not work as you expected, please check and fix source code and send a
patch.

> To avoid confusion how about renaming the mode option as geom (since
> it relates to geometry of rgb components of a pixel) and geom as
> positioning as it affects character layout.

I think we should not use a word "positioning" because Microsoft does
not used.

> It may be useful to document at least the modes.

Indeed. I have wrote enumeration keywords that help users be able to
learn with Microsoft's document, instead of writing detail descriptions
which are arranged by us.

Best.

[KF Leong]

I've issue with this patch on my computer. Compiled using MSVC 2010.

When rop is turn on, the characters display "moved" down, causing
letters with ascenders clipped, i.e. j, q, p etc. Font is Consolas;
encoding is UTF-8.

Image with rop turned off:
http://i.imgur.com/zYIZo6s.png

Image with rop turned on:
http://i.imgur.com/lssJh3p.png

Version string:
<<<<
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Mar 30 2013 13:06:46)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-875
Compiled by kfleong@personal
Huge version with GUI. Features included (+) or not (-):
+arabic +ex_extra +multi_byte_ime/dyn
+tag_old_static
+autocmd +extra_search +multi_lang -
tag_any_white
+balloon_eval +farsi -mzscheme -tcl
+browse +file_in_path +netbeans_intg -tgetent
++builtin_terms +find_in_path +ole -
termresponse
+byte_offset +float +path_extra
+textobjects
+cindent +folding +perl/dyn +title
+clientserver -footer +persistent_undo +toolbar
+clipboard +gettext/dyn -postscript
+user_commands
+cmdline_compl -hangul_input +printer +vertsplit
+cmdline_hist +iconv/dyn +profile
+virtualedit
+cmdline_info +insert_expand +python/dyn +visual
+comments +jumplist +python3/dyn
+visualextra
+conceal +keymap +quickfix +viminfo
+cryptv +langmap +reltime +vreplace
+cscope +libcall +rightleft
+wildignore
+cursorbind +linebreak +ruby/dyn +wildmenu
+cursorshape +lispindent +scrollbind +windows
+dialog_con_gui +listcmds +signs
+writebackup
+diff +localmap +smartindent -xfontset
+digraphs +lua/dyn -sniff -xim
+directx +menu +startuptime -
xterm_save
-dnd +mksession +statusline +xpm_w32
-ebcdic +modify_fname -sun_workshop
+emacs_tags +mouse +syntax
+eval +mouseshape +tag_binary
system vimrc file: "$VIM\vimrc"
user vimrc file: "$HOME\_vimrc"
2nd user vimrc file: "$VIM\_vimrc"
user exrc file: "$HOME\_exrc"
2nd user exrc file: "$VIM\_exrc"
system gvimrc file: "$VIM\gvimrc"
user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$VIM\_gvimrc"
system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 -
DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_XPM_W32 -DWINVER=0x0400 -
D_WIN32_WINNT=0x0400 /Fo.\ObjGXOULYHRi386/ /Ox /GL -DNDEBUG /Zl /MT -
DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DGLOBAL_IME -DFEAT_MBYTE -
DFEAT_GUI_W32 -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DDYNAMIC_ICONV -
DDYNAMIC_GETTEXT -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=
\"lua51.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=
\"python27.dll\" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -
DDYNAMIC_PYTHON3_DLL=\"python33.dll\" -DFEAT_PERL -DDYNAMIC_PERL -
DDYNAMIC_PERL_DLL=\"perl514.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY -
DDYNAMIC_RUBY_VER=191 -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby191.dll\" -
DFEAT_HUGE /Fd.\ObjGXOULYHRi386/ /Zi
Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS
oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib
comdlg32.lib ole32.lib uuid.lib /machine:i386 /nodefaultlib gdi32.lib
version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib /
machine:i386 /nodefaultlib libcmt.lib oleaut32.lib user32.lib /
nodefaultlib:lua51.lib /nodefaultlib:python27.lib /
nodefaultlib:python33.lib WSock32.lib xpm\x86\lib\libXpm.lib /
PDB:gvim.pdb -debug
>>>>

What settings should I use to make it display properly?

KF

[Taro MURAOKA]

Hi Leong:

I have one questions:
Which a patch did you use? patch-direct_write-r3d.diff?

Thanks.

[Taro MURAOKA]

> I have one questions:

Addtion:

Please tell me your settings (result of ":set").

[KF Leong]

On Mar 30, 2:49 pm, Taro MURAOKA <koron.kaor...@gmail.com> wrote:
> > I have one questions:

>
> I have one questions:
> Which a patch did you use? patch-direct_write-r3d.diff?

Yes. FYI running Windows 7 x86, with NVidia graphics card.

> Addtion:
>
> Please tell me your settings (result of ":set").

Here it is:

<<<<<
--- Options ---
autoindent expandtab laststatus=2
showmatch
background=dark foldmethod=marker nrformats=hex
smartcase
cindent guioptions=egmrLt ruler smarttab
confirm helplang=En scroll=11
splitright
cursorline hidden scrolloff=3
tabstop=3
diffexpr=MyDiff() history=50 shellslash wildmenu
encoding=utf-8 incsearch shiftwidth=3 nowrap
backspace=indent,eol,start
cinoptions=:0,(0,u0
completeopt=menu,longest
cpoptions=aABceFsI
directory=.,~\AppData\Local\Temp
fileencodings=ucs-bom,utf-8,default,latin1
formatoptions=tcqj
grepprg=grep -nH $*
guifont=Consolas:h11
guifontwide=NSimSun:h11
omnifunc=syntaxcomplete#Complete
pastetoggle=<C-F5>
runtimepath=~/vimfiles,~\vimfiles\bundle\Align,~\vimfiles\bundle
\Tabular,~\vimfiles\bundle\zencoding-vim,~\vimfiles\bundle\ZoomWin,~
\vimfiles\bundle\neocomplcache,~\vimfiles\bundle\nerdcommenter,~
\vimfiles\bundle\taglist,~\vimfiles\bundle\unicode,~\vimfiles\bundle
\vim-repeat,~\vimfiles\bundle\vim-surround,~\vimfiles\bundle\vim-
unimpaired,~\vimfiles\bundle\yankring,C:\Program Files\vim/vimfiles,C:
\Program Files\vim\vim73,C:\Program Files\vim/vimfiles/after,~\vimfiles
\bundle\Tabular\after,~/vimfiles/after
sessionoptions=blank,buffers,curdir,folds,help,tabpages,winsize
statusline=%<%f %h%m%r%y%=%n|%-14.(%l,%c%V%) %P
whichwrap=b,s,<,>,[,]
<<<<<

HTH
KF

[Mike Williams]

On 29/03/2013 12:55, Taro MURAOKA wrote:
> I updated the patch which attached. I have changed these:
>
> * Add document which describe enum values.
> * Rename "mode" to "renmode".
> * Add "taamode" for text antialising mode.
>
>> there needs to be a call to SetTextAntialiasMode() to specify if
>> grayscale or ClearType anti-aliasing should be done.
>
> I have implemented this. But I don't know is it correct or not. If it
> is not work as you expected, please check and fix source code and send a
> patch.

At the moment I can see no no effect on the rendered output. I don't
know if this is an issue with the implementation or the Windows
documentation. I will investigate further.

>> To avoid confusion how about renaming the mode option as geom (since
>> it relates to geometry of rgb components of a pixel) and geom as
>> positioning as it affects character layout.
>
> I think we should not use a word "positioning" because Microsoft does
> not used.

You are right, they use the word layout. I did not think it was as
clear as talking about the positioning of the characters.

>> It may be useful to document at least the modes.
>
> Indeed. I have wrote enumeration keywords that help users be able to
> learn with Microsoft's document, instead of writing detail descriptions
> which are arranged by us.

Ok.

Mike
--
The Road to Enlightenment is long and difficult, so bring lots of snacks.

[Mike Williams]

On 30/03/2013 15:32, Mike Williams wrote:
> On 29/03/2013 12:55, Taro MURAOKA wrote:
>> I updated the patch which attached. I have changed these:
>>
>> * Add document which describe enum values.
>> * Rename "mode" to "renmode".
>> * Add "taamode" for text antialising mode.
>>
>>> there needs to be a call to SetTextAntialiasMode() to specify if
>>> grayscale or ClearType anti-aliasing should be done.
>>
>> I have implemented this. But I don't know is it correct or not. If it
>> is not work as you expected, please check and fix source code and send a
>> patch.
>
> At the moment I can see no no effect on the rendered output. I don't
> know if this is an issue with the implementation or the Windows
> documentation. I will investigate further.

There is a bug in gui_mch_set_rendering_options() when setting
param.textAntialiasMode, the test is on dx_taamode instead of dx_flags.
However, fixing this does not result in any changes when changing taamode.

Going deeper into the new code, I wonder if the useGdiNatural param to
CreateGdiCompatibleTextLayout() needs to be conditional on the font
created by vim. VIM creates fonts with PROOF_QUALITY so may not be
producing the best output. Still reading through the code.

[Taro MURAOKA]

Mike Williams wrote:
> There is a bug in gui_mch_set_rendering_options() when setting
> param.textAntialiasMode, the test is on dx_taamode instead of dx_flags.

Thank you reporting this!

I have fixed my patch about that. You can get it from here.

https://bitbucket.org/koron/vim-kaoriya-vim-mq-ex/src/2ab295fc4b4695899d9848c0d1b2dbdd01cf20e3/patch-direct_write-r3.diff

Thanks.

[Mike Williams]

Looks ok to me.

I haven't been able to get taamode to have an effect. Googling around,
it may be that it used transparency effects, which since VIM doesn't use
is not needed after all - the online DirectX docs are great on what but
not so much on why. Sorry for sending you on a wild goose chase.

TTFN

Mike
--
Don't be a yes man. When the Boss says no, you say no.

[Taro MURAOKA]

Hi Leong.

I and k-takata tried to reproduce your report on last week end.
But we cannot reproduce it.

To understand cause of your report, please try the binary which I
have compiled.

http://files.kaoriya.net/var/vim73-kaoriya-dw96e-20130401.zip

This archive include both of 32bit and 64bit version of gvim.
Ant it contains DirectWrite patch.

Best.

[KF Leong]

On Apr 1, 9:11 am, Taro MURAOKA <koron.kaor...@gmail.com> wrote:
>
> To understand cause of your report, please try the binary which I
> have compiled.
>
> http://files.kaoriya.net/var/vim73-kaoriya-dw96e-20130401.zip

I've tried the gvim-dw32.exe binary and the problem still exhibits. I
tried on another machine with mine and your binary, it does not
exhibit the problem. Hmm...

I've started gvim with noplugin option and the following _vimrc:

set nocompatible
set encoding=utf8
set cursorline
set guifont=Consolas:h11
set guifontwide=NSimSun:h11

> gvim -n --noplugin

What other information you'd require for you to diagnose?

HTH,
KF

[Taro MURAOKA]

> What other information you'd require for you to diagnose?

Please verify your installed font files: Consolas and NSimSun.
Check those hashes between OK and NG machine, or some method.

I doubt fonts are cause of this issue.

Best.

[KF Leong]

> Please verify your installed font files: Consolas and NSimSun.
> Check those hashes between OK and NG machine, or some method.

The hashes matched on both machines...

KF

[Taro MURAOKA]

Leong

Please check your DPI of screen on your both machines, and tell me those.

Best.

[KF Leong]

> Please check your DPI of screen on your both machines, and tell me those.

Aah, yes DPI setting!!

For the NG machine, DPI set to 125%, while OK machine is at default,
100%.

HTH,
KF

[Taro MURAOKA]

Thank you! And please give me more time to fix it.

[Ken Takata]

Hi Leong and Taro,

2013/04/02 Tue 20:00:43 UTC+9 KF Leong:

Please try this additional patch.
(Sorry If I send this message twice.)

Best regards,
Ken Takata

[Taro MURAOKA]

Thank you Ken!

It seems OK for me.
And I merged your patch and updated mine.

Please check it!

[KF Leong]

>
> Please try this additional patch.

>  dwrite-high-dpi.patch

Tested and it's working as intended.

Regards,
KF

[Taro MURAOKA]

Ken Takata send me another patch to fix typos.
I have merged it and updated the patch.

I hope it would be final version.

[Taro MURAOKA]

I added license notation for new files which I have wrote.
Of course, those are under VIM LICENSE! ;-)

[Mike Williams]

On 14/05/2013 13:24, Taro MURAOKA wrote:
> I added license notation for new files which I have wrote.
> Of course, those are under VIM LICENSE! ;-)

Really hoping this makes into VIM.

Hint.

TTFN

Mike
--
Some push the envelope to the edge. Others just lick it!

[Ken Takata]

Hi,

Using DirectWrite seems to fix the following issue from the todo.txt:

> 8 Win32: Multi-byte characters are not displayed, even though the same font
> in Notepad can display them. (Srinath Avadhanula) Try with the
> UTF-8-demo.txt page with Andale Mono.

Regards,
Ken Takata

[Peter Prohaska]

Appears so. But i suspect, it might be font-linking (or whatever
insert missing glyphs from other/fallback fonts is called). I've
tested this behaviour with various fonts. Testdata contained kyrillic,
sinhala, tamil, hindi, japanese and arabic text. I'm quite sure, those
are not directly supported by all of the fonts.

Regard,
Peter.

[Peter Prohaska]

Pasting text produces inconstisten screen state. Looks like a mixture of
monospaced and proportional font. Resetting rop to empty fixes the
problem--and reintroduces the missing char glyphs.

Attached is screenshot with the lines showing
1) state right after paste (cursor was aligned above the 2nd-row tsu
2) state after moving one character to the left ("h")
3) state after moving left till column 1 ("hhh")

Yank and paste, scroll off screen and back in, all produce state (1).
Selections mark the full width as in state (3). Moving the cursor over a
position triggers the update as seen in state (2).

Test settings:
rop=type:directx
guifont=DejaVu_Sans_Mono:h10:cANSI

Test Build: VC10; Win8; nmake -f Make_mvc.mak GUI=yes DIRECTX=yes


Aside:
It should definitely make it into vim.

Skimmed through the code. Don't know much about the specific job. Looks
solid enough. Patch currelty produces a rejected hunk against hg due to the
addition of 'regexpengine' option.

My user experience: Try a few dozen fonts, find a hadfull that works
acceptable. Pre patch: rest is unusable. Post patch: rest works good or
great. Editing terminological datasets often, i hearty recommend this
pain-killer (or a different OS).

Regards,
Peter.