Unfortunately, this is caused by an inconsistency in Java: for font sizes (int he AWT Font class), the fixed resolution of 72 dpi is used. However, the normal display resolution that should be used for other lengths is around 96 dpi (taken from Toolkit.getDefaultToolkit().getScreenResolution(), probably depends on OS settings). As the result, the font.size contains the pixel size instead of the point size. And that's the explanation for the obtained value: 12*96/72 = 16.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding the parent size: if there is no font-size definition for the element, it is automatically inherited from the parent by jStyleParser. That means we always have a font-size defintion for the element. The parent size is only used for relative font sizes (em and percentages).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I need to re-open this post because the font-size is still confusing me. Look at the screenshot I made. The propery-value window displays 16pt, although I specified 12pt in the style-tag (see window at the right-bottom).
Perhaps, you could convert everything to the java font size in pt, e.g., the margin and the position, and compute the layout in this way? Would it solve the inconsistency bug?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry for the delay - quite busy these days. I have spent quite much time in tuning the font sizes to work in most web pages and the result is the current CSSBox code. I mean the display should be correct although the obtained values are different. This is because Java uses different DPI for fonts and different DPI for the rest of the graphics. I mean the simple solution would be to implement a correct getFontSize() directly in the VisualContext instead of using getFont().getSize(). Would this solve your problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have already thought that you were busy. No problem at all.
An API adaption would not change anything, because JStyleParser computes the positions based on the font size, right?
The BoxBrowser would still not display the same layout as FF and Chrome do (see the comparision https://sourceforge.net/p/cssbox/bugs/19/#b13b). Or is it correct that they differ? In the BoxBrowser screenshot, the row starting with "30" does not fit in the area with the black border, although it does in FF.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, there seems to be a slight difference between Firefox and CSSBox when rendering this page. However, the resulting computed font sizes seem to be the same: both Firefox (using Firebug) and CSSBox indicate 12pt = 16px font. The difference may be caused by Java text drawing routines, the line height computation or anything. I am afraid, it is not possible to achive pixel-accurate results here. Is this necessary for some particular application?
The CSS specification is not very strict regarding the resulting line height of text. It only says that the line height depends on font size but it does not say how. I have chosen some solution experimentally but other browsers may choose another way.
As a web designer I would never rely on a fixed height of anything because different clients have different fonts, screen resolutions etc. Moreover, combining pt and px together is potentially dangerous anyway - the results depend on the acutal display DPI and you may expect problems on mobile devices etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In particular, the font-size of the parent is not used if the child does not define an font-size:
Unfortunately, this is caused by an inconsistency in Java: for font sizes (int he AWT Font class), the fixed resolution of 72 dpi is used. However, the normal display resolution that should be used for other lengths is around 96 dpi (taken from
Toolkit.getDefaultToolkit().getScreenResolution()
, probably depends on OS settings). As the result, the font.size contains the pixel size instead of the point size. And that's the explanation for the obtained value: 12*96/72 = 16.Regarding the parent size: if there is no font-size definition for the element, it is automatically inherited from the parent by jStyleParser. That means we always have a font-size defintion for the element. The parent size is only used for relative font sizes (em and percentages).
I need to re-open this post because the font-size is still confusing me. Look at the screenshot I made. The propery-value window displays 16pt, although I specified 12pt in the style-tag (see window at the right-bottom).
Last edit: Nogge 2013-06-10
Perhaps this is the reason for a layout difference between the BoxBrowser and FF/Chrome (see screenshots below).
Last edit: Nogge 2013-06-10
If I add and use sizeInPt for the java.awt.Font
the BoxBrowser and FF/Chrome look almost the same. The Javadoc of Font requires a size in points, so why do you pass the size in pixel?
Moreover, it is best-practice to choose a variable name that includes its unit, as I did with sizeInPt.
Perhaps, you could convert everything to the java font size in pt, e.g., the margin and the position, and compute the layout in this way? Would it solve the inconsistency bug?
I'm sorry for the delay - quite busy these days. I have spent quite much time in tuning the font sizes to work in most web pages and the result is the current CSSBox code. I mean the display should be correct although the obtained values are different. This is because Java uses different DPI for fonts and different DPI for the rest of the graphics. I mean the simple solution would be to implement a correct getFontSize() directly in the VisualContext instead of using getFont().getSize(). Would this solve your problem?
I have already thought that you were busy. No problem at all.
An API adaption would not change anything, because JStyleParser computes the positions based on the font size, right?
The BoxBrowser would still not display the same layout as FF and Chrome do (see the comparision https://sourceforge.net/p/cssbox/bugs/19/#b13b). Or is it correct that they differ? In the BoxBrowser screenshot, the row starting with "30" does not fit in the area with the black border, although it does in FF.
Hey Radek,
could you please reset the status of this thread? Or don't you work on this topic anymore?
Ok, marked as pending. I will implement the proposed solution asap.
Thank you very much. I count on you ;)
I have added a new getFontSize() method to VisualContext that should return the correct font size in pt. Just for avoiding further confusion.
Regarding the presented layout comparison - is there a source code of that page available? Thanks.
Sorry for the very long delay. I hope you still worry about it and do not forget it. I have posted the code above. Thanks.
Ok, there seems to be a slight difference between Firefox and CSSBox when rendering this page. However, the resulting computed font sizes seem to be the same: both Firefox (using Firebug) and CSSBox indicate 12pt = 16px font. The difference may be caused by Java text drawing routines, the line height computation or anything. I am afraid, it is not possible to achive pixel-accurate results here. Is this necessary for some particular application?
The CSS specification is not very strict regarding the resulting line height of text. It only says that the line height depends on font size but it does not say how. I have chosen some solution experimentally but other browsers may choose another way.
As a web designer I would never rely on a fixed height of anything because different clients have different fonts, screen resolutions etc. Moreover, combining pt and px together is potentially dangerous anyway - the results depend on the acutal display DPI and you may expect problems on mobile devices etc.