[ scintilla-Feature Requests-2812250 ] Enforce the use of ClearType for ClearType-specific fonts

5 views
Skip to first unread message

SourceForge.net

unread,
Jun 27, 2009, 12:23:37 AM6/27/09
to nor...@sourceforge.net
Feature Requests item #2812250, was opened at 2009-06-25 16:15
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=352439&aid=2812250&group_id=2439

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Scintilla
Group: None
Status: Open
Priority: 3
Private: No
Submitted By: Kai Liu (kliu0x52)
Assigned to: Neil Hodgson (nyamatongwe)
Summary: Enforce the use of ClearType for ClearType-specific fonts

Initial Comment:
According to Microsoft, "In GDI, the API for choosing the current font has the rendering type explicitly as input. It is expected that there are situations where the application knows best what type of rendering should be used."

I believe that one of these "application knows best" scenarios is when the application is using one of the new ClearType-specific fonts introduced in Vista/Office2K7. In this case, I believe that the application should explicitly specify the ClearType rendering method so that ClearType is always used to render that particular font, even if the user does not have ClearType set as the default system-wide rendering method.

I have attached a patch for this. I enclosed the new code around an #ifdef ENFORCE_CLEARTYPE so that apps that use Scintilla can explicitly opt-in to the ClearType enforcement. This could be changed to #ifndef NO_CLEARTYPE_ENFORCEMENT if an opt-out is preferred.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-06-27 04:23

Message:
Or perhaps this could be implemented in a way that is similar to how you
handle GDK vs. Pango on Linux: if a font name is prepended with !, then use
the ClearType renderer, otherwise use the system default...

----------------------------------------------------------------------

Comment By: Kai Liu (kliu0x52)
Date: 2009-06-26 00:35

Message:
> If the user has chosen to turn off ClearType in the global settings,
> perhaps they have a reason that we should not attempt to override.

Microsoft never intended the default to be treated as a user preference,
though some people view it that way. Their intent was for it to act as a
fallback in the cases where the application does not care enough to set
something explicit. A number of Microsoft programs (most notably IE7+ and
Office 2007) turn on ClearType for the application even when ClearType is
not the system default. Also, these are specific fonts that most people
would agree are simply not usable without ClearType. In my own usage, I'm
actually not that fond of ClearType, but I cannot unset it as my default
renderer because I need it to be on for fonts like Consolas. And so as an
end-user, my personal preference is for more applications to explicitly
enable ClearType for fonts where ClearType is, pardon the pun, clearly
necessary so that I could run with the default rendering set to something
other than ClearType.

> Sticking explicit lists of fonts in the platform layer is not a very
> general or extensible mechanism.

Yes, I agree. Ideally, an application using Scintilla should be able to
specify whether a particular font should use ClearType. But that would
require a whole new set of messages (SCI_STYLE(G|S)ETQUALITY?) that are
specific to Windows, and I wasn't sure if you would accept something that,
um, invasive. The patch as submitted implements it with the lightest
possible footprint, but if you're okay with the idea of creating a couple
of Windows-specific style APIs, I could cook up a more ideal patch.

----------------------------------------------------------------------

Comment By: Neil Hodgson (nyamatongwe)
Date: 2009-06-25 23:52

Message:
If the user has chosen to turn off ClearType in the global settings,
perhaps they have a reason that we should not attempt to override. Sticking
explicit lists of fonts in the platform layer is not a very general or
extensible mechanism.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=352439&aid=2812250&group_id=2439

SourceForge.net

unread,
Jun 27, 2009, 6:41:42 AM6/27/09
to nor...@sourceforge.net
Feature Requests item #2812250, was opened at 2009-06-26 02:15
Message generated for change (Comment added) made by nyamatongwe

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Scintilla
Group: None
Status: Open
Priority: 3
Private: No
Submitted By: Kai Liu (kliu0x52)
Assigned to: Neil Hodgson (nyamatongwe)
Summary: Enforce the use of ClearType for ClearType-specific fonts

Initial Comment:
According to Microsoft, "In GDI, the API for choosing the current font has the rendering type explicitly as input. It is expected that there are situations where the application knows best what type of rendering should be used."

I believe that one of these "application knows best" scenarios is when the application is using one of the new ClearType-specific fonts introduced in Vista/Office2K7. In this case, I believe that the application should explicitly specify the ClearType rendering method so that ClearType is always used to render that particular font, even if the user does not have ClearType set as the default system-wide rendering method.

I have attached a patch for this. I enclosed the new code around an #ifdef ENFORCE_CLEARTYPE so that apps that use Scintilla can explicitly opt-in to the ClearType enforcement. This could be changed to #ifndef NO_CLEARTYPE_ENFORCEMENT if an opt-out is preferred.

----------------------------------------------------------------------

>Comment By: Neil Hodgson (nyamatongwe)
Date: 2009-06-27 20:41

Message:
Consolas does still work with standard antialiasing and even with
antialiasing turned off although its not pretty.

Can the 'ClearType-specific' nature of a font be determined
programmatically such as from the lfQuality value returned by
EnumFontFamilies? If so then it would be better to do this rather than have
a hard-coded list. It would still be good to have some control over whether
this happens.

An explicit quality setting would be better than a name munge as it could
be extended if needed. Initially there'd just be a default value and a
cleartype-on-windows value but cross-platform settings may be possible
later. Pango appears to offer no parameter for quality.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-06-27 14:23

Message:
Or perhaps this could be implemented in a way that is similar to how you
handle GDK vs. Pango on Linux: if a font name is prepended with !, then use
the ClearType renderer, otherwise use the system default...

----------------------------------------------------------------------

Comment By: Kai Liu (kliu0x52)

Date: 2009-06-26 10:35

----------------------------------------------------------------------

Date: 2009-06-26 09:52

SourceForge.net

unread,
Jun 30, 2009, 10:24:34 AM6/30/09
to nor...@sourceforge.net
Feature Requests item #2812250, was opened at 2009-06-25 12:15
Message generated for change (Comment added) made by kliu0x52

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Scintilla
Group: None
Status: Open
Priority: 3
Private: No
Submitted By: Kai Liu (kliu0x52)
Assigned to: Neil Hodgson (nyamatongwe)
Summary: Enforce the use of ClearType for ClearType-specific fonts

Initial Comment:
According to Microsoft, "In GDI, the API for choosing the current font has the rendering type explicitly as input. It is expected that there are situations where the application knows best what type of rendering should be used."

I believe that one of these "application knows best" scenarios is when the application is using one of the new ClearType-specific fonts introduced in Vista/Office2K7. In this case, I believe that the application should explicitly specify the ClearType rendering method so that ClearType is always used to render that particular font, even if the user does not have ClearType set as the default system-wide rendering method.

I have attached a patch for this. I enclosed the new code around an #ifdef ENFORCE_CLEARTYPE so that apps that use Scintilla can explicitly opt-in to the ClearType enforcement. This could be changed to #ifndef NO_CLEARTYPE_ENFORCEMENT if an opt-out is preferred.

----------------------------------------------------------------------

Comment By: Kai Liu (kliu0x52)
Date: 2009-06-30 10:24

Message:


> Can the 'ClearType-specific' nature of a font be determined
> programmatically such as from the lfQuality

No, it cannot be.

I think that it's probably best to leave this up to the application using
Scintilla and just have Scintilla provide a way for the application to
specify that it prefers ClearType--let the application do the enforcement
if it wants to.

To that end, I've noticed that there is an "extraFontFlag" member in Font
and ViewStyle that looks like it's reserved and currently unused (it's
always false)...

1) Do you have any plans for this "extraFontFlag" member, or am I free to
make use of this for the patch?

2) If I can use it, would you object to me changing it from a bool to an
int so that it can be further extended in the future (e.g., used as a
bitfield)?

3) Would you prefer that the setting be a simple on/off "default vs.
ClearType", or would you prefer that we allow the application to set any
font quality (e.g., forcing antialiasing to be off)? The latter would be
perhaps more useful for the application (though if we go by precedent, the
font weight as implemented by Scintilla is just bold/non-bold even though
there are other possible values, like demibold).

----------------------------------------------------------------------

Comment By: Neil Hodgson (nyamatongwe)

Date: 2009-06-27 06:41

Message:
Consolas does still work with standard antialiasing and even with
antialiasing turned off although its not pretty.

Can the 'ClearType-specific' nature of a font be determined
programmatically such as from the lfQuality value returned by
EnumFontFamilies? If so then it would be better to do this rather than have
a hard-coded list. It would still be good to have some control over whether
this happens.

An explicit quality setting would be better than a name munge as it could
be extended if needed. Initially there'd just be a default value and a
cleartype-on-windows value but cross-platform settings may be possible
later. Pango appears to offer no parameter for quality.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-06-27 00:23

Message:
Or perhaps this could be implemented in a way that is similar to how you
handle GDK vs. Pango on Linux: if a font name is prepended with !, then use
the ClearType renderer, otherwise use the system default...

----------------------------------------------------------------------

Comment By: Kai Liu (kliu0x52)

Date: 2009-06-25 20:35

----------------------------------------------------------------------

Date: 2009-06-25 19:52

SourceForge.net

unread,
Jul 1, 2009, 6:42:06 AM7/1/09
to nor...@sourceforge.net
Feature Requests item #2812250, was opened at 2009-06-26 02:15
Message generated for change (Comment added) made by nyamatongwe

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Scintilla
Group: None
Status: Open
Priority: 3
Private: No
Submitted By: Kai Liu (kliu0x52)
Assigned to: Neil Hodgson (nyamatongwe)
Summary: Enforce the use of ClearType for ClearType-specific fonts

Initial Comment:
According to Microsoft, "In GDI, the API for choosing the current font has the rendering type explicitly as input. It is expected that there are situations where the application knows best what type of rendering should be used."

I believe that one of these "application knows best" scenarios is when the application is using one of the new ClearType-specific fonts introduced in Vista/Office2K7. In this case, I believe that the application should explicitly specify the ClearType rendering method so that ClearType is always used to render that particular font, even if the user does not have ClearType set as the default system-wide rendering method.

I have attached a patch for this. I enclosed the new code around an #ifdef ENFORCE_CLEARTYPE so that apps that use Scintilla can explicitly opt-in to the ClearType enforcement. This could be changed to #ifndef NO_CLEARTYPE_ENFORCEMENT if an opt-out is preferred.

----------------------------------------------------------------------

>Comment By: Neil Hodgson (nyamatongwe)
Date: 2009-07-01 20:42

Message:
extraFontFlag was added for the wxWidgets platform to control ...
antialiasing. Changing it to an int may cause compatibility issues for
wxWidgets. This should really be discussed on the mailing list and may
require talking to the wxWidgets people. They may be interested in changing
to an enumerated quality field.

----------------------------------------------------------------------

Comment By: Kai Liu (kliu0x52)

Date: 2009-07-01 00:24

Message:
> Can the 'ClearType-specific' nature of a font be determined
> programmatically such as from the lfQuality

No, it cannot be.

I think that it's probably best to leave this up to the application using
Scintilla and just have Scintilla provide a way for the application to
specify that it prefers ClearType--let the application do the enforcement
if it wants to.

To that end, I've noticed that there is an "extraFontFlag" member in Font
and ViewStyle that looks like it's reserved and currently unused (it's
always false)...

1) Do you have any plans for this "extraFontFlag" member, or am I free to
make use of this for the patch?

2) If I can use it, would you object to me changing it from a bool to an
int so that it can be further extended in the future (e.g., used as a
bitfield)?

3) Would you prefer that the setting be a simple on/off "default vs.
ClearType", or would you prefer that we allow the application to set any
font quality (e.g., forcing antialiasing to be off)? The latter would be
perhaps more useful for the application (though if we go by precedent, the
font weight as implemented by Scintilla is just bold/non-bold even though
there are other possible values, like demibold).

----------------------------------------------------------------------

Comment By: Neil Hodgson (nyamatongwe)

Date: 2009-06-27 20:41

Message:
Consolas does still work with standard antialiasing and even with
antialiasing turned off although its not pretty.

Can the 'ClearType-specific' nature of a font be determined
programmatically such as from the lfQuality value returned by
EnumFontFamilies? If so then it would be better to do this rather than have
a hard-coded list. It would still be good to have some control over whether
this happens.

An explicit quality setting would be better than a name munge as it could
be extended if needed. Initially there'd just be a default value and a
cleartype-on-windows value but cross-platform settings may be possible
later. Pango appears to offer no parameter for quality.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-06-27 14:23

Message:
Or perhaps this could be implemented in a way that is similar to how you
handle GDK vs. Pango on Linux: if a font name is prepended with !, then use
the ClearType renderer, otherwise use the system default...

----------------------------------------------------------------------

Comment By: Kai Liu (kliu0x52)

Date: 2009-06-26 10:35

----------------------------------------------------------------------

Date: 2009-06-26 09:52

Reply all
Reply to author
Forward
0 new messages