Re: CSS Font size in points doesn't match Node.Font.Size
It can and should. See my previous post. If there is no JIRA for this, then please create one. Thanks, Steve On 2014-03-05 6:18 PM, Tom Schindl wrote: The question the is why fairly all other toolkits use point in their APIs. Some examples: * Qt: http://qt-project.org/doc/qt-5/qfont.html#QFont-2 * Cocoa: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFont_Class/Reference/Reference.html#//apple_ref/occ/clm/NSFont/fontWithName:size: * Pango: https://developer.gnome.org/pango/stable/pango-Fonts.html#pango-font-description-set-size * AWT: http://docs.oracle.com/javase/7/docs/api/java/awt/Font.html#Font%28java.lang.String,%20int,%20int%29 * SWT: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fgraphics%2FFont.html Why can't JavaFX not at least provide a font-API to create fonts with point? Tom On 05.03.14 23:59, David Grieve wrote: Everyone should just accept that there is no such thing as a 'point' in JavaFX. Work in pixels and you will achieve nirvana. On 3/5/14, 5:49 PM, Pedro Duque Vieira wrote: Here is the definition of point: http://www.w3schools.com/cssref/css_units.asp As Jeff is saying it should be 1/72 inch. I think this should be the default. Isn't the introduction of modena potentially going to break more apps than changing the definition of point? Aren't breaking apps making use of a bug that they shouldn't be taking advantage of in the first place? That being said, and if changing the default point definition is not really possible, being able to change this through a global settings property so that node matches CSS, sound like a reasonable workaround. Thanks!
Re: CSS Font size in points doesn't match Node.Font.Size
Hey Felipe, I recall a couple of years ago when Phil drilled it into me that Font size was pixels. So when you said that Font size is point, I was skeptical. But, indeed, you are correct and I am mistaken. I see now that setting font size from point units in our CSS is broken. Our CSS implementation will convert -fx-font-size: 12pt; to 9px since CSS says that 72/96th of a point equals a pixel. But that should convert to 12px. Fortunately, modena and caspian are all pixel based units. It is important to note that if the assertion that DPI=72 ever changes, then CSS will be broken since I've (incorrectly) assumed all along that Font size is pixels. On 3/6/14, 1:47 PM, Felipe Heidrich wrote: On Mar 5, 2014, at 3:18 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Why can't JavaFX not at least provide a font-API to create fonts with point? The current JavaFX API is point (see the doc). The thing is, on the desktop it uses DPI=72, so px=pt. In the printer the actual device DPI is used (so that 72pt=1in on the paper). Note, Mac is exactly the same, see the doc for CTFontRef for example https://developer.apple.com/library/mac/documentation/Carbon/Reference/CTFontRef/Reference/reference.html#//apple_ref/doc/uid/TP40005110 It talks about point size the very same way JavaFX does. That is so true that the very value passed to Font.font(double) is passed to CTFontCreateWithName() in CTFontStrike.java as is. The same is true for Windows, using DirectWrite and Linux, using FreeType. Felipe
Re: CSS Font size in points doesn't match Node.Font.Size
Hi David On Mar 6, 2014, at 11:37 AM, David Grieve david.gri...@oracle.com wrote: I see now that setting font size from point units in our CSS is broken. It depends how you judge. If you compare the result of our CSS to any browser then our handling of point size in your CSS is correct. fx-font-size=12pt [In JFX] == font-size=12pt [In any UA] if you change that you too will break user. IMO the one thing we can do is to add a switch (either to Node or CSS) so allow DPI to be set, so that 12pt in Node and CSS match. Felipe
Re: CSS Font size in points doesn't match Node.Font.Size
On 3/6/14, 4:10 PM, Phil Race wrote: I think your sum is backward. If 0.75pts==1 pixel then a 12 pt font will be 16 pixels. Exactly why my wife doesn't let me near the checkbook.
Re: CSS Font size in points doesn't match Node.Font.Size
Hi On Mar 4, 2014, at 4:42 PM, Jeff Martin j...@reportmill.com wrote: Thanks Tom! I assume the thread was this one: Font.font() says it is point size but it looks like it are pixels http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html I guess the final word is that CSS assumes 1pt==1/92in, Yes and Nodes convert that to the real world on render? On the printer yes, on the display it assumes 72 (pt=px). And that this is basically a bug, but it can't be fixed due to legacy considerations? Yes Felipe On Mar 4, 2014, at 6:10 PM, Tom Schindl tom.schi...@bestsolution.at wrote: There was a thread some time ago on this List with explainations of this behavior! Tom Von meinem iPhone gesendet Am 05.03.2014 um 01:03 schrieb Jeff Martin j...@reportmill.com: I can't quite wrap my head around why when I specify an -fx-font-size of 9pt in CSS, it turns into a 12 pt font in my rendered node. I suppose CSS is upscaling for my 96 dpi device, but it makes other measurements that depend on that setting potentially wrong. Any suggestions on how I should be thinking about this (other than that this is a bug :-)? jeff
Re: CSS Font size in points doesn't match Node.Font.Size
From my tests the font size generated by CSS is what one gets with the same point size and font using native apps and Qt - my complaint was the font size when using the Java API. Tom Von meinem iPhone gesendet Am 05.03.2014 um 23:03 schrieb Felipe Heidrich felipe.heidr...@oracle.com: The problem is that point size used by Node and point size used by CSS are not the same. One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. I don’t see how to change one or the other without breaking a ton of people. Maybe adding a global font DPI so that Node can be made to match CSS ? Suggestions ? Felipe On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi Tom, Jeff, Felipe... Having bugs stay in to maintain backwards compatibility sounds very weird to me IMHO. If we go down that road aren't we creating a library that will some day have too many glitches and as such less appeal to programmers looking for UI libraries? Thanks, Hi On Mar 4, 2014, at 4:42 PM, Jeff Martin j...@reportmill.com wrote: Thanks Tom! I assume the thread was this one: Font.font() says it is point size but it looks like it are pixels http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html I guess the final word is that CSS assumes 1pt==1/92in, Yes and Nodes convert that to the real world on render? On the printer yes, on the display it assumes 72 (pt=px). And that this is basically a bug, but it can't be fixed due to legacy considerations? Yes Felipe -- Pedro Duque Vieira
Re: CSS Font size in points doesn't match Node.Font.Size
I don't think we can do what you suggest about the warning, since there are cases where CSS could be initialized prior to calling into the application (e.g., the default preloader, deploy dialogs), but I think it might make sense to add a property to control the scale. Can you file a JIRA request for adding such a property? I think we can argue separately whether it should be the default at some point, but I am not in favor of that. This would be too big of a breaking change. -- Kevin Jeff Martin wrote: The thing is, point size is a fixed size - 1pt==1/72 in, regardless of the DPI. It is simply incorrect and confusing, arbitrarily deciding that a point is 1/96in. How about implementing the fix based on a global static variable somewhere? And perhaps printing a warning to the console when the first CSS is applied if that global hasn't been set saying, CSS point-size fix not activated - this will be set by default in a future release. jeff On Mar 5, 2014, at 4:03 PM, Felipe Heidrich felipe.heidr...@oracle.com wrote: The problem is that point size used by Node and point size used by CSS are not the same. One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. I don’t see how to change one or the other without breaking a ton of people. Maybe adding a global font DPI so that Node can be made to match CSS ? Suggestions ? Felipe On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi Tom, Jeff, Felipe... Having bugs stay in to maintain backwards compatibility sounds very weird to me IMHO. If we go down that road aren't we creating a library that will some day have too many glitches and as such less appeal to programmers looking for UI libraries? Thanks, Hi On Mar 4, 2014, at 4:42 PM, Jeff Martin j...@reportmill.com wrote: Thanks Tom! I assume the thread was this one: Font.font() says it is point size but it looks like it are pixels http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html I guess the final word is that CSS assumes 1pt==1/92in, Yes and Nodes convert that to the real world on render? On the printer yes, on the display it assumes 72 (pt=px). And that this is basically a bug, but it can't be fixed due to legacy considerations? Yes Felipe -- Pedro Duque Vieira
Re: CSS Font size in points doesn't match Node.Font.Size
Hi all, To change the Java API now would break the universe. All you can do is add new API. This can be in the form of new methods on Font, however things like Font.getSize() must always return pixels. A new method can be added getPoints() and new constructors that take points added, or perhaps a boolean parameter that says the the double parameter is in points, not pixels. A global mode would be horrible and error prone (unless I am missing something). Steve On 2014-03-05 5:19 PM, Tom Schindl wrote: From my tests the font size generated by CSS is what one gets with the same point size and font using native apps and Qt - my complaint was the font size when using the Java API. Tom Von meinem iPhone gesendet Am 05.03.2014 um 23:03 schrieb Felipe Heidrich felipe.heidr...@oracle.com: The problem is that point size used by Node and point size used by CSS are not the same. One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. I don’t see how to change one or the other without breaking a ton of people. Maybe adding a global font DPI so that Node can be made to match CSS ? Suggestions ? Felipe On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi Tom, Jeff, Felipe... Having bugs stay in to maintain backwards compatibility sounds very weird to me IMHO. If we go down that road aren't we creating a library that will some day have too many glitches and as such less appeal to programmers looking for UI libraries? Thanks, Hi On Mar 4, 2014, at 4:42 PM, Jeff Martin j...@reportmill.com wrote: Thanks Tom! I assume the thread was this one: Font.font() says it is point size but it looks like it are pixels http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html I guess the final word is that CSS assumes 1pt==1/92in, Yes and Nodes convert that to the real world on render? On the printer yes, on the display it assumes 72 (pt=px). And that this is basically a bug, but it can't be fixed due to legacy considerations? Yes Felipe -- Pedro Duque Vieira
Re: CSS Font size in points doesn't match Node.Font.Size
Here is the definition of point: http://www.w3schools.com/cssref/css_units.asp As Jeff is saying it should be 1/72 inch. I think this should be the default. Isn't the introduction of modena potentially going to break more apps than changing the definition of point? Aren't breaking apps making use of a bug that they shouldn't be taking advantage of in the first place? That being said, and if changing the default point definition is not really possible, being able to change this through a global settings property so that node matches CSS, sound like a reasonable workaround. Thanks! -- Pedro Duque Vieira
Re: CSS Font size in points doesn't match Node.Font.Size
Everyone should just accept that there is no such thing as a 'point' in JavaFX. Work in pixels and you will achieve nirvana. On 3/5/14, 5:49 PM, Pedro Duque Vieira wrote: Here is the definition of point: http://www.w3schools.com/cssref/css_units.asp As Jeff is saying it should be 1/72 inch. I think this should be the default. Isn't the introduction of modena potentially going to break more apps than changing the definition of point? Aren't breaking apps making use of a bug that they shouldn't be taking advantage of in the first place? That being said, and if changing the default point definition is not really possible, being able to change this through a global settings property so that node matches CSS, sound like a reasonable workaround. Thanks!
Re: CSS Font size in points doesn't match Node.Font.Size
There was a thread some time ago on this List with explainations of this behavior! Tom Von meinem iPhone gesendet Am 05.03.2014 um 01:03 schrieb Jeff Martin j...@reportmill.com: I can't quite wrap my head around why when I specify an -fx-font-size of 9pt in CSS, it turns into a 12 pt font in my rendered node. I suppose CSS is upscaling for my 96 dpi device, but it makes other measurements that depend on that setting potentially wrong. Any suggestions on how I should be thinking about this (other than that this is a bug :-)? jeff
Re: CSS Font size in points doesn't match Node.Font.Size
Thanks Tom! I assume the thread was this one: Font.font() says it is point size but it looks like it are pixels http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html I guess the final word is that CSS assumes 1pt==1/92in, and Nodes convert that to the real world on render? And that this is basically a bug, but it can't be fixed due to legacy considerations? jeff On Mar 4, 2014, at 6:10 PM, Tom Schindl tom.schi...@bestsolution.at wrote: There was a thread some time ago on this List with explainations of this behavior! Tom Von meinem iPhone gesendet Am 05.03.2014 um 01:03 schrieb Jeff Martin j...@reportmill.com: I can't quite wrap my head around why when I specify an -fx-font-size of 9pt in CSS, it turns into a 12 pt font in my rendered node. I suppose CSS is upscaling for my 96 dpi device, but it makes other measurements that depend on that setting potentially wrong. Any suggestions on how I should be thinking about this (other than that this is a bug :-)? jeff
