Bug 455995

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. 

I've filed a bug with upstream about this issue: 

https://sourceforge.net/tracker/index.php?func=detail&aid=2023902&group_id=89513&atid=590374

.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
issue.

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
non-interactively.

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

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".

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.

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.

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).

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.

Just changing the container format to OTF won't transform quadratic splines in
cubic you know.

Created attachment 312405 [details]
Screenshot for the unbelievers.

(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.

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
http://www.redhat.com/archives/fedora-fonts-list/2008-July/msg00059.html

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... ;-) )

Created attachment 312487 [details]
Mystery screenshot 1

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.
quadratic.

Still it is a valid basis for comparison.

Created attachment 312489 [details]
"I'm am clueless" screenshot 1

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...

Last note on this: all test were with fonts generated at 2048em.

(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.

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
patent?

All screenshots were from pango-view.

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

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

Vasile, are you saying that XeTeX can't use TrueType OpenType fonts and only
handles CFF OpenType?

(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.

ok, so where are we here? 

Shall we just stick with the truetype fonts?

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.

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.