That's not true. There is a difference in the "white" space around the letters. The "white" pixel before the stem of the L is not 100% white in either case and the difference is in line with what I would expect if there was a sub-pixel shift..
Scott On Thu, Mar 6, 2014 at 1:51 PM, Phil Race <philip.r...@oracle.com> wrote: > There really isn't any evidence of that. If it were true you'd see the > blending > into the pixels either side, but the pixels either side of the stem are > 100% > white in both cases. And examining the subpixels inside the extremities of > the stem backs me up ... > > -phil. > > > On 3/6/2014 10:40 AM, Scott Palmer wrote: > >> 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<mailto: >> 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> >> <mailto: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>> >> [mailto: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, >> >> >> >> >> >> >> >> >
