Bug 455995 - No OpenType
Summary: No OpenType
Alias: None
Product: Fedora
Classification: Fedora
Component: linux-libertine-fonts
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Frank Arnold
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-19 22:39 UTC by Vasile Gaburici
Modified: 2008-07-29 22:13 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-07-29 22:13:59 UTC
Type: ---

Attachments (Terms of Use)
Screenshot for the unbelievers. (10.13 KB, image/png)
2008-07-22 23:13 UTC, Vasile Gaburici
no flags Details
Mystery screenshot 1 (54.34 KB, image/png)
2008-07-23 15:19 UTC, Vasile Gaburici
no flags Details
Mystery screenshot 2 (59.82 KB, image/png)
2008-07-23 15:21 UTC, Vasile Gaburici
no flags Details
"I'm am clueless" screenshot 1 (29.03 KB, image/png)
2008-07-23 15:30 UTC, Vasile Gaburici
no flags Details
"I'm am clueless" screenshot 2 (24.35 KB, image/png)
2008-07-23 15:34 UTC, Vasile Gaburici
no flags Details

Description Vasile Gaburici 2008-07-19 22:39:43 UTC
Description of problem:

OpenType variants of the fonts (available from upstream) are not packaged. These
are usable with XeTeX which Fedora now ships in texlive.

Comment 1 Kevin Fenzi 2008-07-21 19:38:25 UTC
Odd. I see the .otf files in the binary distribution, but they don't seem to be
providing the .fea files for otf fonts, and I can't get the sdf files to
generate otf files either. 

Comment 2 Kevin Fenzi 2008-07-21 20:23:32 UTC
I've filed a bug with upstream about this issue: 


Comment 3 Vasile Gaburici 2008-07-22 10:52:42 UTC
.fea files are an Adobe standard. FontForge can export and import them, but
normally stores the OpenType features inside it's own .sfd files, together with
the glyphs. So the upstream doesn't need to provide .fea files, although working
with text .fea files, like Adobe's foundry does, has some definite advantages. I
posted the link to an Adobe ATypl presentation on the fedora-fonts-list on this

As for generating OpenType CFF fonts, I have no trouble doing it from the
FontForge "File/Generate Fonts..." menu; just choose "OpenType (CFF)" as output
format. My FontForge scripting skills are lacking, so I don't know how to do it

Btw, the link for the bug report doesn't work for me.

Comment 4 Kevin Fenzi 2008-07-22 19:11:43 UTC
I have tried to generate them via a fontforge script, but it runs into some
error condition and fails. I would be happy to talk to fontforge folks and see
how to script this, but... 

Upstream says: 

"I produce them by transforming Libertines EM from
2048 down to 1000 and then with generate font files...."

This means that the otf versions are going to be lower quality and suffer from
rounding issues anyhow. Why not just use the ttf ones?

Sorry the link didn't work, sourceforge is junk. It has different links based on
if you are logged in or not. 

If you go to http://sourceforge.net/projects/linuxlibertine/ and then 'tracker'
you should be able to see the bug under "feature requests".

Comment 5 Vasile Gaburici 2008-07-22 21:23:39 UTC
Well, I'm currently working with "upstream" Philipp to improve Romanian support.
So I had to export the fonts myself to OpenType/CCF. With the 20080607 version
of fontforge, I get a warning that 2048 is an unusual value (the usual being
1000), but the export is otherwise successful. E.g. na OTF with support for
ROM/locl is  here: http://www.cs.umd.edu/~gaburici/ro/LinLibertine.otf. It
doesn't look to me that any downscaling took place.

Comment 6 Vasile Gaburici 2008-07-22 21:31:30 UTC
Update: actually for the font I just gave you a link, I do get a warning when I
open it in fontforge: "Stack got too big in uniE00A In LinLibertine, in glyph
uniE00A, 'CFF ' advance width (1556) and'hmtx' width (2874) do not match.
(Subsequent mismatches will not be reported)". The glyph E00A is the Libertine
logo, which is quite complex. But other glyphs have no trouble. I'll point
Philipp to this thread. Maybe, he can shed some light, or perhaps simplify the
logo a bit, so we can get high quality OTF.

Comment 7 Nicolas Mailhot 2008-07-22 21:42:59 UTC
You don't need OTF for the features you care about. TTF is as much a valid
OpenType format as OTF.

2048 is the default TrueType grid. That strongly hints the font was designed for
the TrueType format. By converting to OTF you're winning absolutely nothing
quality-wise (and lose OO.o compatibility).

Comment 8 Vasile Gaburici 2008-07-22 21:47:22 UTC
I know that TTF is valid OpenType, but the curves are not cubic in TT, are they?

I checked the E00A glyph in my font and the original, and mine cannot be
displayed by pango-view, so fontforge complains for good reason.

Comment 9 Nicolas Mailhot 2008-07-22 22:27:42 UTC
Just changing the container format to OTF won't transform quadratic splines in
cubic you know.

Comment 10 Vasile Gaburici 2008-07-22 23:13:01 UTC
Created attachment 312405 [details]
Screenshot for the unbelievers.

Comment 11 Vasile Gaburici 2008-07-22 23:15:28 UTC
(In reply to comment #9)
> Just changing the container format to OTF won't transform quadratic splines in
> cubic you know.

No, but exporting the original sfd as OpenType/CFF will! Maybe you should open
the sources and tell us which part or "All layers cubic" you don't undrestand.
See screenshot!

Btw, support for Romanian locl has been completed by Philipp with a little help
from me. So expect a new version upstream anyway.

Comment 12 Nicolas Mailhot 2008-07-23 08:54:47 UTC
Oh well, I really didn't want to tackle dual OTF/TTF packaging now, especially
for a font which is highly likely to be used in OO.o.

Please comment on

Comment 13 Ben Laenen 2008-07-23 11:19:34 UTC
I dare you to look at the rendered output of the ttf and otf glyphs at one 
meter size and pick out the ones with the cubic splines... Really, the 
quadratic splines which are made from the cubic ones really are virtually the 
same quality, and if you overlay both you can only really see it at very big 
sizes, certainly not the sizes you get out of your printer, let alone from 
your computer screen. Your brain also won't be able to tell which is the 
better curve (except you're some kind of superhuman with capabilities for 
visually making accurate derivatives of the curves... ;-) )

Comment 14 Vasile Gaburici 2008-07-23 15:19:37 UTC
Created attachment 312487 [details]
Mystery screenshot 1

Comment 15 Vasile Gaburici 2008-07-23 15:21:32 UTC
Created attachment 312488 [details]
Mystery screenshot 2

Which one do you find easier to read, this or the previous screenshot?

Btw, I realize this has more to do with hinting rather than cubic vs.

Still it is a valid basis for comparison.

Comment 16 Vasile Gaburici 2008-07-23 15:30:05 UTC
Created attachment 312489 [details]
"I'm am clueless" screenshot 1

Comment 17 Vasile Gaburici 2008-07-23 15:34:45 UTC
Created attachment 312491 [details]
"I'm am clueless" screenshot 2

OTOH, at lager (display) sizes, it's impossible to tell the difference. A good
way to check is to overlap the maximized image viewer windows and gradually
fade out one of them, e.g. using compiz's Alt+SrollWheel feature.

In conclusion, I was full of hot air on the cubic vs. quadratic issue. Hinting
matters a lot more for the user experience...

Comment 18 Vasile Gaburici 2008-07-23 15:37:34 UTC
Last note on this: all test were with fonts generated at 2048em.

Comment 19 Ben Laenen 2008-07-23 15:40:18 UTC
(In reply to comment #15)

Well, you've said it yourself, that's not an issue of quadratic vs cubic 
splines. Freetype can do automatic hinting as well if you want. And Fontforge 
can make automatic ttf hinting instructions as well. This is not an issue of 
ttf being better or worse than otf, but these otf having hinted added by 
FontForge and the ttf not. If you manually hint the ttfs, the situation will 
be the other way around.

Comment 20 Vasile Gaburici 2008-07-23 15:48:45 UTC
Two questions:
1) Isn't the auto-hinter on by default?
2) Isn't the state machine-based ttf hinting unusable in Fedora due to Apple's

All screenshots were from pango-view.

Comment 21 Ben Laenen 2008-07-23 15:54:10 UTC
1) depends on the distro. I think fedora has it on by default, but you can 
easily change it yourself
2) yeah, but many will turn on the bytecode interpreter anyway with third 
party packages

Comment 22 Nicolas Mailhot 2008-07-23 18:35:13 UTC
If the only difference you see is from one font version being autohinted by
fontforge, and the other not, there is a bug in the way the autohinter is
configured on your system and the bug should be reassigned to pango and the
pango maintainer.

Of course the other solution would be for the libertine packager to script
addition of hints to its truetype, but system autohinting is supposed to make
that unecessary

Comment 23 Behdad Esfahbod 2008-07-23 19:28:00 UTC
Vasile, are you saying that XeTeX can't use TrueType OpenType fonts and only
handles CFF OpenType?

Comment 24 Vasile Gaburici 2008-07-23 21:06:42 UTC
(In reply to comment #23)
> Vasile, are you saying that XeTeX can't use TrueType OpenType fonts and only
> handles CFF OpenType?

No, XeTeX can "handle" both flavors of OpenType. I put handle in quotes because
XeTeX internally generates an exteneded dvi (.xdv), which is then ran through a
driver to produce pdf; I don't think postscript output is possible. One can tell
XeTeX to write the xdv to a file, but I don't know of any viewers for xdv. 

On Linux the driver that converts xdv to pdf is xdvipdfmx. (On Macs one can also
choose xdv2pdf, which makes use of AAT - Apple's Advanced Typography). So, font
support on Linux is entirely dependent on what xdvipdfmx does. Given that the
extended dvi stuff was originally developed for East Asian languaes, the English
documentation is a bit spotty. Here's what I've been able to determine:
- both TrueType and and OpenType/CFF are supported and are embedded in the pdf.
- for both formats xdvipdfmx uses the CID encoding for the embedded font. XeTeX
understands only UTF-8. The conversion of encodings is handled transparently by
xdvipdfmx, and the pdf is searchable except for ligatures. (In contrast, pdftex
1.4 can handle those correctly).
- there is confusion whether "bare" type-1 fonts are well supported or not by
xdvipdfmx. I've seen things go both ways. The default fonts for XeTeX are Latin
Modern, which come as type-1 (and work). Unfortunately, in Fedora you cannot
select them manually (say after switching to another font set), because that
requires the OTF files, which Fedora doesn't ship. TeXLive upstream includes
both type-1 and OTF/CFF versions of Latin Modern. To further complicate this
issue, direct type-1 support was apparently added in Feb 2008 for fonts that
support the EU1 (TeX) encoding, which apparently is exactly Unicode. See this:
http://www.ctan.org/tex-archive/macros/xetex/latex/euenc/. Insofar I refrained
from filing a bug on Fedora's TeXLive for missing the Latin Modern OTF's...
- finally, xdvipdfmx searches both the traditional TeX map paths and makes use
of fontconfig to find fonts. I think fontconfig takes precedence.

 at least when PDFs are generated. I was living under the misguided impression
that CFF was superior for printing.

Comment 25 Kevin Fenzi 2008-07-29 02:53:10 UTC
ok, so where are we here? 

Shall we just stick with the truetype fonts?

Comment 26 Vasile Gaburici 2008-07-29 07:25:12 UTC
I'd say do nothing for now, that is stick to TTFs.

The long term plan in Fedora is (now) to prefer CFF OTFs, and upstream Philipp
also likes it that way. But the 2.8 LL has some problems with 2048em OTFs: the
font logo (U+E00A) is broken in Pango, and worse, I'm getting all glyphs broken
if I include LL as 2048em OTF in a XeTeX pdf, but the downscaled 1000em OTF
works fine with XeTeX. This could be a bug in dvipdfmx because it converts OTFs
to type 1 CID before inclusion... The 2048em TTF works better for now.

Comment 27 Kevin Fenzi 2008-07-29 22:13:59 UTC
ok. Closing this bug now. 

Thanks for all the info, and please do reopen or file a new bug when you think
we should look at switching to the OTF's.

Note You need to log in before you can comment on or make changes to this bug.