Will gdipp add internal font link support in the future?

[GoogleCodeExporter]

I think it would be more safe and efficient to manipulate the internal font 
link rather than the registry one.

Original issue reported on code.google.com by novelk...@gmail.com on 22 Sep 2010 at 11:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Not in my recent plan. There are some reasons:

1) Implementing such feature is not a trivial task. Significant amount of XML 
and setting code needs to be carefully written. Also, The setting file 
structure will be changed, which is the top priority thing that we want to 
avoid.

2) Windows has the exactly same feature implemented internally, and effective 
in all programs and fonts. Duplicating such feature and only applying to gdipp 
is cost inefficient.

3) Implementing features like font substituting only for gdipp would introduce 
severe compatibility issues. Currently, gdipp depends heavily on GDI APIs to 
minimize potential incompatible code. These gdipp-only feature will bypass 
GDI's sanity check and font fallback. It will be likely to crash when a Latin 
script font is replaced by an Asian script font.

4) It would not be more efficient, in context of performance, to manipulate 
internal font link than the registry one. Everything is cached in memory, and 
it is meaningless to design different data structure to store and use the 
internal font link against the registry one. As of 3), it would be only less 
safe to do so.

Original comment by crendk...@gmail.com on 22 Sep 2010 at 11:26

[GoogleCodeExporter]

That makes sense.

Original comment by novelk...@gmail.com on 23 Sep 2010 at 4:19

[GoogleCodeExporter]

Original comment by crendk...@gmail.com on 23 Sep 2010 at 9:21

• Changed state: WontFix