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.
Hi David
On Mar 6, 2014, at 11:37 AM, David Grieve 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] =
> Our CSS implementation will convert -fx-font-size: 12pt; to 9px
> since CSS says that 72/96th of a point equals a pixel
I think your sum is backward. If 0.75pts==1 pixel then a 12 pt font will
be 16 pixels.
Perhaps another way of looking at this is that the CSS "1 pixel=1/96
inch" approxima
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 implem
On Mar 5, 2014, at 3:18 PM, Tom Schindl 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
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#QF
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/
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
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
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
pe
To set the record straight, everything in JavaFX is pixels, including
Font size.
The W3C CSS spec (http://www.w3.org/TR/css3-values/#absolute-lengths)
defines 1px to be 1/96th of 1in and 1pt to be 1/72 of 1in. Therefore,
one px is 3/4ths of a pt (1px = 0.75pt) and this is the conversion
facto
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 reque
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 :
>
>
> The problem is that point
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 f
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
I’m not a CSS guy, but I never seen an alternative as you suggest.
I suppose there is recommend way to handle this problem.
Looking at modena.css it always uses “em” to define font size (instead of pt or
px).
Wouldn’t that work for you ?
Felipe
On Mar 5, 2014, at 9:51 AM, Jeff Martin 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,
So what is the best approach to dealing with pt sizes in CSS? Do I multiply
every pt size by 3/4 in CSS? Will this always result in Node Fonts that are 4/3
times the specified CSS value?
I assume I can't just use px and expect Node Fonts to have the identical value,
only in points, regardless o
Hi
On Mar 4, 2014, at 4:42 PM, Jeff Martin 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 tha
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
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 :
>
> 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
21 matches
Mail list logo
