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 <j...@reportmill.com> wrote:

> 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 of the display.
> 
> Maybe Region should have a new attribute called FixCSSPoints that we could 
> set after adding style sheets?
> 
> jeff
> 
> 
> On Mar 5, 2014, at 10:09 AM, Felipe Heidrich <felipe.heidr...@oracle.com> 
> wrote:
> 
>> 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
>>> 
>> 
> 

Reply via email to