Lineheight of TTF and OTF not the same in Java

[DanielRuf]

There are some differences when I am using the fonts on Windows 7 in Java 7 (Swing):

ttf:

otf:

Seems the lineheight varies btween those 2. Is this issue related to the fonts themself or is it a Swing issue?
@miguelsousa @adobe

https://forums.oracle.com/thread/2573652

[miguelsousa]

Not a font issue, I think.
I checked the values in the OS/2 and hhea tables and they're the same in both font formats. The files tested were SourceSansPro-Regular.(otf/ttf) version 1.050.

[DanielRuf]

Ok thanks. So this might be a Java7 (Swing, Nimbus L&F) issue.

[DanielRuf]

@miguelsousa

I have tried http://ipanemagrafica.rede.gl/carme/

And with this font it looks like this:

ttf:

otf:

And the values are also the same in FontForge

[miguelsousa]

@DanielRuf I'm failing to understand how you're coming to the conclusion that the problem is in the fonts. Do you happen to know how Java7 does vertical layout, and which data it collects from the fonts to accomplish it?

[DanielRuf]

I will recheck this.

Hopefully Oracle/the OpenJDK team can confirm that this is a bug but he says it is not a Java or Nimbus/Swing but but in the font files: http://stackoverflow.com/a/18462739/753676

But I think you are rgiht. What I don't understand is why this happens (this has to be a bug in Java) but even this experienced (Java) user on Stackoverflow tells me something other (but he did not prove the opposite)

Currently this bug is unfortunately a blocker for an application but I am very sure that this is a Java bug (hopefully Oracle will react much faster this time to provide a solution)

I will use this issue here for the bug report to Oracle because here we have the fonts, links, screenshots and additional information (source code of the files)

[miguelsousa]

OK, please keep us posted. We appreciate your feedback, and we're open to consider tweaking the fonts. But as far as I can tell this vertical difference in the layout should not be happening, because the two font formats have exactly the same vertical metrics that are used by apps when they layout things vertically. Those values are in the OS/2 table -- sTypoAscender, sTypoDescender, sTypoLineGap, usWinAscent, usWinDescent -- and in the hhea table -- Ascender, Descender, LineGap.

[DanielRuf]

Thanks for the info about the important values so I know where to look exactly. Sure, I will keep you posted.

[DanielRuf]

@miguelsousa
It seems this tool solved the issue, but why?

http://onlinefontconverter.com/font

Here is a zip file with the old and new files which were processed by the online font converter tool:
http://www.filedropper.com/source-sans-pro-fixed

[miguelsousa]

Is the vertical spacing of the modified fonts like the original OTF or like the original TTF? Screenshots please.

[DanielRuf]

@miguelsousa
I do not know how to check this. Did you examine the fonts in the zip file?
Which program or (CSS) code should I use to test this?

They both lokk same in the browser:

Also the height of both elements is the same.

I do not see any difference in the height or vertical spacing?

[miguelsousa]

I did look at the fonts. They have too many differences from the original, so my comparison was inconclusive. (If you're interested in comparing the fonts, the best way is to convert them to XML using TTX http://sourceforge.net/projects/fonttools/)

I also compiled the Java examples and my results were:

1. Both the original TTF and the modified TTF displayed the same way
2. The original OTF and the modified OTF displayed differently from each other
3. The modified TTF and the modified OTF still displayed differently from each other

Below are the screenshots I took.

TTF original

TTF modified

OTF original

OTF modified

I still don't understand why the TTFs and the OTFs are not aligning the same way. But one thing I can say (from looking at the TTX dumps) is that all 4 fonts have the same vertical metrics values in the OS/2 table. So, taking this info and the results into account, my guess for what's happening is:
A. For TrueType fonts (.ttf) Java uses the values in the OS/2 table.
B. For OpenType fonts (.otf) Java uses an heuristic
(C. The heuristic used for OT fonts is probably the same as the one used for Type 1 fonts)

[DanielRuf]

Also the original OTF and TTF are a bit different. The font weight seems to be different/one of the fonts looks more crips and the other a bit more blurry (is this a feature of OTF compared to TTF?).

Right, this is what the others also found out. But fixing the fonts also fixed the OTF font version.
I also looked into the font information in FontForge and also saw that all 4 fonts have the same values.
So why is the fixed version displayed correctly but the original font file not?

mkorbel at stackoverflow always says that it is not a Java bug (fonts were fixed by the online font converter tool and it works now).

So how should B possible?
I still do not understand this issue. Where is the issue? The font files themselves? Can this be fixed in the original files somehow?

It seems we have to ask some other experts and need some more info why this is happening.
Who could we ask for help? Is there some expert for fonts who could take a look at this or could you send him/her a link to this issue here?

[miguelsousa]

Also the original OTF and TTF are a bit different. The font weight seems to be different/one of the fonts looks more crips and the other a bit more blurry (is this a feature of OTF compared to TTF?).

This is due to the different outline formats and to the rasterizers that render the glyphs.

But fixing the fonts also fixed the OTF font version. [...] So why is the fixed version displayed correctly but the original font file not?

You're saying that the fonts are fixed yet the TTF modified image and the OTF modified image are significantly different in terms of vertical spacing. So what does "fixed" mean to you? I thought it meant TTF = OTF.
Also, what makes you say that the fixed OTF displays correctly? I look at OTF modified and to me it's actually worse than OTF original.

mkorbel at stackoverflow always says that it is not a Java bug

I read the thread and I see nowhere being explained WHY it's not a Java bug. Does mkorbel have access to Java's source code? Does he know how Java uses the font data internally?

(fonts were fixed by the online font converter tool and it works now).

Which ones? Certainly not the ones you pointed me to, because as you can see above TTF modified does NOT look the same as OTF modified.

So how should B possible?

A, B and C are just my guesses; to know for sure you'd have to ask someone at Oracle who's familiar with the internals of Java in regards to font handling.

Can this be fixed in the original files somehow?

If my guesses A and B are correct, than the answer is No. The fix would have to be made on the Java source code. That fix being: For OpenType fonts (.otf) use the values in the OS/2 table.

It seems we have to ask some other experts and need some more info why this is happening. Who could we ask for help?

Agree. You should try to find a developer of Java (not a Java developer) that knows about how the fonts are handled internally.

Is there some expert for fonts who could take a look at this or could you send him/her a link to this issue here?

Err, I am a font expert. I've gone above and beyond to test this issue, and I thought I had made my argument about this issue not being a font bug very clear. But you're more than welcome to seek a second opinion.

[DanielRuf]

@miguelsousa which Java version did you use? I used Java 7 U45.
I already tried to file a bug report at Oracle for Java, but it seems their Bugtracker gave me a bug ID but the bug was not created?

Sorry for the part about the font expert, I did not know or know very little about you and how you are involved with this.

Currently there are the arguments from the Stackoverflow user mkorbel vs your arguments and me in between.
He says it is not a Java bug and you say it is a Java bug.
Now I am very confused.

But I believe that you know more about the fonts and the rasterizers and values than mkorbel.
This makes all things more complicated and confusing.

[miguelsousa]

Java Version 1.7.0_45 from Oracle Corporation

If you don't mind my asking, why is it important to you to have parity between OTF and TTF in Java?

[DanielRuf]

Because OTF fonts in Java are supported in almost all operating systems but I think TTF not?
http://mindprod.com/jgloss/opentype.html

Or is this chart outdated for Java?

[miguelsousa]

I would say it's the opposite. Because it's an earlier format, TTF fonts are supported in more places than OTF fonts.

[DanielRuf]

Mh, so TTF is better? But OTF hs more features compared to OTF or am I wrong? Like ligatures?
Because I have learned as mediadesigner that OTF is better and has some special features which TTF does not have.

[miguelsousa]

It's not a matter of being better or worse, it's a matter of working better or worse depending on the platform you're deploying the fonts on. TTF fonts can have as many OpenType features as OTF fonts. I can't speak for other fonts, but in Source Sans you'll get exactly the same functionality regardless of the font format you choose. Apart from the differences in the format of the outlines, the OTF and TTF files are basically identical.

[mKorbel]

@miguelsousa

my view (just copy-paste my comment from OPs question, with a few fixes) in several points

1. this will be accepted as offical bug in the case that only one of JComponents caused by different layout, bug could be in the case that JTextField (then JComboBox too) cause with this issue, for example there is bug in Java7 (still not Offical) with (java.swing.)View for JTextComponents, there is difference between APIs docs and binnary source, – mKorbel 10 hours ago, addendum multi_lines JTextComponent has an several issues starting with wordwrap, ends with layout in column and rows
2. a) font can be registred in Native OS, b) font can be registred in JVM only, have to test if is there some difference, – mKorbel 10 hours ago
3. there isn't any difference between Java6 and Java7 as is demonstrated in my answer here and for various Standard LookAndFeels on various WinOS version, there is important fact that renderings core is very different for WinXP and for Win7/8, then my answers is that isn't Java bug – mKorbel 10 hours ago
4. most of Java bug are accesible only from SystemLookAndFeels (WindowsLook...) or WindowsClassicLook..., in this case the result is same for Nimbus too (only one different rendering algorithm in Swing APIs) – mKorbel 10 hours ago
5. my question is now (do not take as flamewar) - for why reasons one part of font is rendered correctly (after font is converted, fixed), second isn't, there is possible to calculate required Rectange from SwingUtilities.(layoutCompoundLabel, e.i.) but by default there isn't some direct way to get this height (everything is about how to computeStringWidth), this value came from Font and isn't directly accesible from deriveFont for Graphics too, – mKorbel 10 hours ago
6. if is there any different conclusion I can to abuse my rep power, to ask question here about how to get, set, manage required height for Fonts from Graphics, because these setting for JComponents are in BasicXxxUI, there is everything about paint/paintText, but I'm think that layout for this font in Graphics will be the same as for JComponents in my code example – mKorbel 10 hours ago

addendum, I can't resist

1. we can to forgot about custom font converter, this is not solution, can help us in specifics situations, when (for example) text atributes, some Unicode glyphs missing or aren't correctly renderer, missing there some size(s),
2. I tried some custom fonts without this specifics issue, do you know if is there another font pair of OTF/TTF, never see this issue with font and wrong layout on all forums where I member of (sure this is not an argument for you)
3. nothing personal, all respect for what people are doing something extra, :-) then another guy evaluates this act as deficiencies, my sorry

[miguelsousa]

do you know if is there another font pair of OTF/TTF

I'm sure there are other projects out there that provide the fonts in both formats, but I can't think of any right now.

[DanielRuf]

There are some fonts with OTF and TTF version on http://fontsquirrel.com and http://ipanemagrafica.rede.gl/carme/

[mKorbel]

better, for example FiraSansOT-Regular.otf caused with this issue, but only for JComboBox (win7/8 java6/7)

[mKorbel]

reference codes for testing Fonts on fly http://stackoverflow.com/questions/9311720/how-to-change-jlabel-font-size-to-fill-jpanel-free-space-while-resizing

[DanielRuf]

So it is a Java bug?

[mKorbel]

not or yes I think BasicComboBoxRenderer that is responsible for standard painting in those fonts correctly, you can to find some layout disproporcies on selection for standard Fonts (Win8) in JComboBoxes JList, Items have got very different layout and they aren't correctly laid by comparing with the same selection in MsWord/Excell2013

e.g. Aharoni, Blackadder ITC, Corbel (my endless lazyness to kill me to continue...)

[DanielRuf]

"not or yes"

I would say yes, definitely.
When they are displayed correctly in other applications but not Java, then it is a Java bug.
Or how do you want to prove the opposite?

[mKorbel]

:-) excluding fact that tested in MsOffice2013, this isn't quilified SW for comparing, there are milions dollars for simple development, issue with font isn't there allowed

you can try to create a new trace in BugParade,

[DanielRuf]

@mKorbel "you can try to create a new trace in BugParade"
what exactly do you mean? What BugParade?
I already tried to file a Java bug, got a bug ID but the a bug with this ID does not exist.

Sorry but your english is very hard to read.

[DanielRuf]

@miguelsousa still not fixed =( and @mKorbel did not help at all, so this will not be fixed in the font itself but Java (Oracle) has to provide a patch? I have filed a bug in the past, got a bug ID but it seems the bug search does not find a bug report for this ID

[miguelsousa]

I know this problem is not resolved, but it's not a font bug, so I closed this issue.

[DanielRuf]

ok, I hope Oracle and their community reacts and finally fixes this bug! =(

[miguelsousa]

Hope so too.