I think the stem of the L is colored differently because of *sub-pixel*
differences in its position.  I.e. it appears to be at the same integer
position, but it isn't at the same real position.  It looks to me like that
alone could account for the differences.

Scott


On Thu, Mar 6, 2014 at 1:35 PM, Phil Race <philip.r...@oracle.com> wrote:

> Does the evidence really support that ?
> You only need to look at the first letter "L". The stem is in
> exactly the same place isn't it? And yet the colours are different.
>
> The overall length is different which I attribute to rounding differences
> or metrics differences used in accumulating the position but that is a
> guess.
>
> -phil.
>
>
> On 3/6/2014 10:25 AM, Scott Palmer wrote:
>
>> If you notice, in the images provided, the length of the rendered text in
>> pixels is significantly different between the two examples.  That supports
>> the theory that it is simply, sub-optimal positioning of the glyphs that is
>> resulting in the more pronounced LCD anti-aliasing.
>>
>> Scott
>>
>>
>> On Thu, Mar 6, 2014 at 1:19 PM, Phil Race <philip.r...@oracle.com<mailto:
>> philip.r...@oracle.com>> wrote:
>>
>>     Perhaps the gamma adjustment is different ?
>>     FX should pick this up from the
>>     SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST setting.
>>
>>     I don't know what Outlook (*) uses if its a WPF app then maybe its
>>     picking
>>     up an over-ridden setting for this from the registry :
>>     http://msdn.microsoft.com/en-us/library/aa970267%28v=vs.
>> 110%29.aspx#gamma_level
>>     You should be able to check that out fairly easily,and you can use
>>     this
>>     JDK app to see what the SystemParameterInfo setting is.
>>
>>     import java.awt.*;
>>     import java.util.*;
>>     public class GetGamma {
>>       public static void main(String args[]) {
>>          Toolkit tk = Toolkit.getDefaultToolkit();
>>          Map map = (Map)tk.getDesktopProperty("awt.font.desktophints");
>>          if (map != null) {
>>           for (Object k : map.keySet()) {
>>                 System.out.println(k + " : "  + map.get(k));
>>          }
>>        }
>>      }
>>     }
>>
>>     C:\>c:\jdk1.8\bin\java GetGamma
>>     Text-specific antialiasing enable key : LCD HRGB antialiasing text
>>     mode
>>     Text-specific LCD contrast key : 120
>>
>>     (*) I'm sure Outlook used to be a GDI app, but who knows what
>>     version you are using
>>     and what rendering technology it uses.
>>     I've tried to make the point many times before that someone can
>>     always point to
>>     a difference from 'native' rendering simply because the platforms
>>     like OS X and Windows
>>     have multiple rasterisers and multiple font technologies all of
>>     which are different
>>     from each other.  So whilst any notably 'poor' rendering needs to
>>     be looked into
>>     it maybe sometimes an artifact of one rendering path compared to
>>     another ..
>>
>>     -phil.
>>
>>
>>     On 3/6/2014 1:21 AM, Robert Fisher wrote:
>>
>>         Hi all,
>>
>>         I think there is still room for improvement in terms of the
>>         'contrast' or 'vibrancy' of fonts in JavaFX. Take a look at
>>         this example:
>>
>>         http://i.imgur.com/6qSamTO.png
>>
>>         I'm running Windows 7. What you are seeing is a screenshot of
>>         the default font, zoomed in 600%. The top text is JavaFX 8
>>         (latest build as of 3 days ago). The bottom text is Outlook
>>         but could just as easily have been Firefox, Chrome, Word, or
>>         Eclipse SWT - they're all indistinguishable to me.
>>
>>         The JavaFX text doesn't look as vibrant. In particular the
>>         smoothing algorithm seems to be making poor colour choices for
>>         the vertical strokes. At 100% the difference is subtle but
>>         important.
>>
>>         I have the text fill set to Color.BLACK and the font smoothing
>>         type set to LCD. Is there something else I can configure to
>>         get more vibrant-looking fonts?
>>
>>         Cheers!
>>         Rob
>>
>>
>>         -----Ursprüngliche Nachricht-----
>>         Von: openjfx-dev-boun...@openjdk.java.net
>>         <mailto:openjfx-dev-boun...@openjdk.java.net>
>>         [mailto:openjfx-dev-boun...@openjdk.java.net
>>
>>         <mailto:openjfx-dev-boun...@openjdk.java.net>] Im Auftrag von
>>         Stephen F Northover
>>         Gesendet: Mittwoch, 5. März 2014 18:30
>>         An: Pedro Duque Vieira; OpenJFX Mailing List
>>         Betreff: Re: Poor font rendering..
>>
>>         Hi Pedro,
>>
>>         Font rendering in FX8 is using the native rasterizer so the
>>         glyphs should be identical to what the operating system is
>>         rendering.  That said, we may have a bug. Please enter a JIRA
>>         with sample code and a screen shot of the bad rendering.  That
>>         will give us something concrete to work with.
>>
>>         Thanks,
>>         Steve
>>
>>         On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote:
>>
>>             Hi,
>>
>>             As evidenced by the screenshots in
>>             http://pixelduke.wordpress.com/
>>             blog posts about JMetro, javafx as noticeably poor font
>>             rendering
>>             visuals. The most recent screenshots were taken on a
>>             windows 8.1
>>             machine and the older ones on windows 7, using Segoe UI
>>             (windows 7 & 8 system font).
>>
>>             1- As this been reported?
>>
>>             2- Is the javafx team working on it?
>>
>>             3- Is there something the developer can do to increase
>>             font rendering
>>             quality?
>>
>>             Thanks!
>>             Best regards,
>>
>>
>>
>>
>>
>>
>

Reply via email to