Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Am Freitag, den 18.07.2014, 21:00 + schrieb Karl Berry: I hadn't realized that the ligatures only failed with non-fully-embedded PDF's. Such PDF's are inherently defective; it's been a long time since Adobe recommended anything but full embedding (not that I think we must kowtow to everything Adobe says, but anyway). So maybe it would actually be a good thing for ligatures to lose :), so that people fix the PDF's where the problem originates That's good advice, but non-fully-embedded PDFs are already in the wild, especially in the academic field. It would be a shame if the FOSS stack could not render them correctly because of some technical details. And in this specific case the ad-hoc fix would be a trivial fix in the font files. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On Mon, 21 Jul 2014, Fabian Greffrath wrote: especially in the academic field. It would be a shame if the FOSS stack could not render them correctly because of some technical details. And in this specific case the ad-hoc fix would be a trivial fix in the font files. Until the next font exhibits the same problem with poppler ... I don't see why fixing something down at a leaf is a good solution, while there is a *canonical* way to fix this at the source of the problem. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Am Donnerstag, den 17.07.2014, 20:57 -0400 schrieb James Cloos: A patch has at least been proposed for poppler to treat glyph names like /f_i as equivilent to names like /fi, at least for the f-ligs found in the standard pdf font encodings for the base14 fonts. I am still convinced (and as far as I understand it seems that at least Karl Berry agrees in that regard) that the most portable solution would be to include duplicates of the two fl/f_l and fi/f_i glyphs that are part of the MacRoman character set in the fonts - in addition to and independent of the fixes in poppler. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/18/2014 1:35 PM, Fabian Greffrath wrote: Am Donnerstag, den 17.07.2014, 20:57 -0400 schrieb James Cloos: A patch has at least been proposed for poppler to treat glyph names like /f_i as equivilent to names like /fi, at least for the f-ligs found in the standard pdf font encodings for the base14 fonts. I am still convinced (and as far as I understand it seems that at least Karl Berry agrees in that regard) that the most portable solution would be to include duplicates of the two fl/f_l and fi/f_i glyphs that are part of the MacRoman character set in the fonts - in addition to and independent of the fixes in poppler. of course that will then fail again when someone drops in another times replacement that doesn't have the /ff if dropping in otf files for type 1 ones is considered a valid solution, then poppler should do more checking anyway for the few f related ligatures (which makes me wonder why the otf file is used as drop-in) (apart from potential issues in one-to-one slot-to-name mapping resolvers in other programs that now can get confused when ff overloads f_f) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
HH == Hans Hagen pra...@wxs.nl writes: HH if dropping in otf files for type 1 ones is considered a valid HH solution, then poppler should do more checking anyway for the few f HH related ligatures (which makes me wonder why the otf file is used as HH drop-in) Poppler asks fontconfig for a font with whatever name the pdf specifies; it gets back whatever fontconfig provides. (IIRC, it does map the 14 abbreviations like TiRo, Symb, ZaDb, et cetera to the full names before doing the lookup.) For the vast majority of applications, it is better for fontconfig to provide SFNT fonts rather than T1. It is reasonable to expect apps and libs which do only need the glyphs properly to handle that. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
as far as I understand it seems that at least Karl Berry agrees in
that regard)
I hadn't realized that the ligatures only failed with non-fully-embedded
PDF's. Such PDF's are inherently defective; it's been a long time since
Adobe recommended anything but full embedding (not that I think we must
kowtow to everything Adobe says, but anyway). So maybe it would
actually be a good thing for ligatures to lose :), so that people fix
the PDF's where the problem originates
Just FWIW, I use the script below to embed PDF's that I receive
unembedded (generally graphics destined for TUGboat).
karl
#!/bin/sh
# ps2pdf (or pdf2pdf), but
# always embedding fonts,
# avoiding bitmap tampering,
# and allowing just one filename arg, meaning overwrite.
# Some parameters from Jacko's zdistill.rip.
: ${gs=gs}
if test $# -eq 1; then
set - $1 $1.tmppdf
fi
$gs \
-q -dNOPAUSE -dBATCH \
-sDEVICE=pdfwrite \
-sOutputFile=$2 \
-dCompatibilityLevel=4 \
-dAutoRotatePages=/None \
-dEmbedAllFonts -dPDFX=true \
-dUseFlateCompression=true \
-dCompressPages=true \
-dASCII85EncodePages=false \
-dEncodeColorImages=true -dDownsampleColorImages=false \
-dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode \
-dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode \
-dEncodeGrayImages=true -dDownsampleGrayImages=false \
-c .setpdfwrite \
-f $1 quit.ps
if test x$2 = x$1.tmppdf; then
mv $2 $1
fi
exit $?
# ps2pdf is a front-end to gs. For a complete list of options, see
# http://ghostscript.com/doc/current/Ps2pdf.htm
#
# By default, gs encodes all images contained in a PS file using
# the lossy DCT (i.e., JPEG) filter. This often leads to inferior
# result (see the discussion at http://electron.mit.edu/~gsteele/pdf/).
# The -dAutoFilterXXXImages and -dXXXImageFilter options used
# below force all images to be encoded with the lossless Flate (zlib,
# same as PNG) filter. Note that if the PS file already contains DCT
# encoded images (which is possible in PS level 2), then these images
# will also be re-encoded using Flate. To turn the conversion off,
# simply remove the options mentioned above.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
HH == Hans Hagen pra...@wxs.nl writes: HH As you mention in a previous mail, it's a bug in poppler (or maybe HH some library it uses) that somehow used glyph names. The bug shows up when the pdf file does not embed the font, forcing viewers and renderers to find a substitute font. A patch has at least been proposed for poppler to treat glyph names like /f_i as equivilent to names like /fi, at least for the f-ligs found in the standard pdf font encodings for the base14 fonts. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Hello again, Am Mittwoch, den 02.07.2014, 16:32 +0200 schrieb Boguslaw Jackowski: Having thought the matter over and having looked into TG Linux packages, we would suggest to use, anyway, Type 1 TG as legacy fonts and to change appropriately the content of packages -- and maybe names? ;-) This won't be that easy, I am afraid. The aliasing of Times - Termes has already made it into fontconfig upstream (modulo a just recently added comment around these lines motivated by the very issue we are just discussing here): http://cgit.freedesktop.org/fontconfig/tree/conf.d/30-metric-aliases.conf#n80 This means, that every application using fontconfig (which shuold be close to 100% on the Linux desktop) that requests a font compatible to Times for rendering will get passed Termes instead by fontconfig. Please note that the font's names are written as e.g. TeX Gyre Termes which does only apply to the OpenType fonts and not to the Type 1 fonts, which are called like TeXGyreTermes, i.e. without the additional blanks. It will take at least one stable release cycle of each major distribution to get this mess cleaned up, I am afraid. * For the sake of compatibility -- even if it was not initially intended that way -- couldn't we simply add the two missing ligature glyphs under their old-style names for the time being and be done with it, please? * Hans: I think that for that embedding the times and so is kind of mandate nowadays. Isn't Times one of the fonts that are by definition of the PDF standard explicitely not required to get embedded? - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/7/2014 10:08 AM, Fabian Greffrath wrote: Isn't Times one of the fonts that are by definition of the PDF standard explicitely not required to get embedded? Those 7+bit times of a default minimal set of 15 fonts (these were embedded in printers which at some point made sense due to bandwidth et etc) are behind us. Of course most printers will still have these fonts because they are part of old standards. Not embedding a font has no benefits and for archival pdf (a/x) fonts have to be embedded. (Nowadays a mediocre picture taken by some gadget takes more space than a font in a document.) In fact, if I get a pdf file with no fonts embedded and it doesn't show up ok, I'd not even bother figuring out why and simple discard the pdf. Now, adding ff as well as f_f to a font mapping to the same glyph might work ok for applications that look for ff but it might as well confuse applications that like to see f_f (think of a one-to-one mapping: which one wins ff - some slot or f_f - slot ?). So, i guess some testing is needed as fixing one and breaking another set of applications doesn't help. So, all applications that want to support the old stuff and new stuff need to support (ff, f_f) = slot mapping. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
FWIW, I don't see how adding ff and the like to the OT fonts simply as independent glyphs for rendering, not related to any OT or Unicode ligature mechanism, could confuse anything. I agree the real bug is in poppler (and/or Debian's choice of using these OT fonts without sufficient testing), but on the other hand, GUST foundry has always tried hard to work with the world as it is, rather than how it should be. karl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/2/2014 4:32 PM, Boguslaw Jackowski wrote: Hans: I think even the type1 texgyre isn't by definition metric compatible. Metric compatibility was one of the major targets of the TeX Gyre project. Sure, definitely for the type1s, but also that for opentype we would not be strict (one never knows what follow up we will have). Visually there are of course differences (accent placement etc) so one can expect visual differences when doing trickery that depends on exact visual properties (like putting multiple accents on top of things) in which case probably even the type1 drop in could be a problem. (I'm talking tex now where open type fonts don't have the type1/tfm relates limitations in w/h/d). In practice a document that doesn't embed and expects e.g. times is not typeset that clever so problems are unlikely to show up. (Users who don't embed shouldn't complain about quality of rendering anyway.) Hans ps. A way bigger nightmare can be lucida as there are many incompatible variants of that one and then there are also cross platform viewing issues. But I assume these are normally embedded, but even then bad things can happen, e.g. with included images in documents that have no embedded fonts too. But afaik we left that time behind us. - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Fabian: they are not installed by default, that is. But once they are installed, they take precedence. OK, we took a shortcut. :-) Incidentally, Debian/Ubuntu distribution ofers either tex-gyre or fonts-texgyre packages, the former containing fonts in the Type 1 format, the latter -- fonts in OpenType format. And a user, having chosen the latter package, is thus forced to use OpenType as replacement fonts, while the formr package cannot be used for this purpose. JP: What about using Type 1 fonts for compatibility purposes? Fabian: We have chosen to use the OpenType fonts for text rendering, because they are generally considered to be better rendered on screen. Maybe the reason behind generally better rendering is that the fonts that render better are internally TrueType (B-spline) fonts, while TeX Gyre fonts are actually CFF (i.e., practically the same as Type 1). It seems that screen-hinted B-spline fonts are usually indeed better rendered. So, we woulnd't expect the difference in the case of TeX Gyre/Latin Modern. Hans: The texgyre opentype fonts are not supposed to be drop ins for those standard (15 or so) ps fonts. Agreed, as we already wrote. Hans: I think even the type1 texgyre isn't by definition metric compatible. Metric compatibility was one of the major targets of the TeX Gyre project. Rare incompatibilities with respect to the original metric files are carefully documented in the relevant documentation. Having thought the matter over and having looked into TG Linux packages, we would suggest to use, anyway, Type 1 TG as legacy fonts and to change appropriately the content of packages -- and maybe names? ;-) Cheers -- Jacko Piotr -- BOP s. c. ul. Bora-Komorowskiego 24, 80-377 Gdansk, Poland tel./fax (+48 58) 553 46 59 b...@bop.com.pl, http://www.bop.com.pl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Am Dienstag, den 01.07.2014, 08:08 +0900 schrieb Norbert Preining: or adding another fake glyph fi/f_i, Yes, please. This sounds like the best compromise: It retains backward and forward compatibility, should be trivial to implement and should be safe for future changes that poppler (or any other rendering framework) introduce. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/1/2014 1:40 PM, Fabian Greffrath wrote: Am Dienstag, den 01.07.2014, 08:08 +0900 schrieb Norbert Preining: or adding another fake glyph fi/f_i, Yes, please. This sounds like the best compromise: It retains backward and forward compatibility, should be trivial to implement and should be safe for future changes that poppler (or any other rendering framework) introduce. I have no clue what this will solve. Say that the original input stream has this: effe = e f i e and the feature processor turns that into glyph representing e glyph representing fi glyph representing e which in the pdf stream can become 121 with 1 pointing glyph representing e and 2 representing fi. The pdf file has then this mapping with fi being named f_i and not fi (why should it) and also carries a tounicode which maps the 1 to unicode e and 2 to unicodes f followed by i. The reference to ff never ends up in the subsetted file. Just fix poppler, because it it has this problem with f_i it definitely has more such problems. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On Tue, Jul 1, 2014 at 2:13 PM, Hans Hagen pra...@wxs.nl wrote: The pdf file has then this mapping with fi being named f_i and not fi (why should it) and also carries a tounicode which maps the 1 to unicode e and 2 to unicodes f followed by i. The reference to ff never ends up in the subsetted file. I suspect that the pdf was created using glyph names and metrics for Times, where fi and not f_i is used, but the font was not embedded. On viewing the pdf, the font used instead of Times was the OpenType version of TeX Gyre Termes, which has no glyph named fi. In this case it should help to supply copies of the ligature glyphs using old style names (fi and fl only). cheerio ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/1/2014 6:12 PM, Ralf Stubner wrote: On Tue, Jul 1, 2014 at 2:13 PM, Hans Hagen pra...@wxs.nl wrote: The pdf file has then this mapping with fi being named f_i and not fi (why should it) and also carries a tounicode which maps the 1 to unicode e and 2 to unicodes f followed by i. The reference to ff never ends up in the subsetted file. I suspect that the pdf was created using glyph names and metrics for Times, where fi and not f_i is used, but the font was not embedded. On viewing the pdf, the font used instead of Times was the OpenType version of TeX Gyre Termes, which has no glyph named fi. In this case it should help to supply copies of the ligature glyphs using old style names (fi and fl only). Isn't it better then to install the standard ps set on the operating system and make sure these are not remapped? The texgyre opentype fonts are not supposed to be drop ins for those standard (15 or so) ps fonts. I think even the type1 texgyre isn't by definition metric compatible. It might be interesting to see how other viewers/operating systems behave (e.g. do mupdf based viewers have the same side effect?) I think that for that embedding the times and so is kind of mandate nowadays. Those big cjk fonts are often extern but these have well defined vectors. Personally I'd not spend a second on a user complaint that concerns a not-embedded font. (Btw, a bigger issue is actually that only a few viewers do 'copy' well i.e. deal with tounicode vectors.) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Hi Norbert, Am Samstag, den 28.06.2014, 15:28 +0900 schrieb Norbert Preining: Thanks, I forwarded this to the poppler group - I am not very optimistic that they will do anything in this direction, but we should try at least ;-) whom do you mean with the poppler group? I couldn't find any message on the poppler-dev mailing list. However, I have also forwarded this information to the bug report I opened against poppler: https://bugs.freedesktop.org/show_bug.cgi?id=80093 - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On Mon, 30 Jun 2014, Fabian Greffrath wrote: whom do you mean with the poppler group? I couldn't find any message I reassigned https://bugs.freedesktop.org/show_bug.cgi?id=73291 to poppler (after some ping pong beteen fontcnfig and poppler) and mentioned the AGL Specification. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Am Montag, den 30.06.2014, 17:03 +0900 schrieb Norbert Preining: I reassigned https://bugs.freedesktop.org/show_bug.cgi?id=73291 to poppler (after some ping pong beteen fontcnfig and poppler) and mentioned the AGL Specification. Ah, I see. I have added the other bug to the See Also list (which I assume is a pendant to Debian's blog a by b thing). - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Norbert:
here at Debian recently a problem surfaced with respect to the
OpenType TeX Gyre fonts.
The problem is that the ligatures are named
f_i
etc while display engines like poppler, as well as the orginal
PostScript fonts, use
fi
etc.
In Debian and Ubuntu, currently the TeX Gyre fonts provide the
*standard* postscript fonts, due to be considered generally
better.
But that means, that at the current moment of one uses the TeX Gyre
fonts as a replacement for the PS fonts, the ligatures will not be
rendered at all.
[...]
Related bug reports are:
* Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742767
* FreeDesktop: https://bugs.freedesktop.org/show_bug.cgi?id=73291
Dear Colleagues,
we are more than happy that the TeX Gyre collection
of fonts has been have been chosen as a default
font set in Debian distribution. And we are
sorry that we haven't predicted the problem
of the discrepancy between the new and old
ligatures name.
Our idea was to provide partially new fonts.
More precisely, we have assumed that the fonts in the
Type 1 format should be as compatible as possible
with the Adobe original fonts. In particular, we tried
to preserve (with some exceptions, due to obvious Adobe's
bugs) the original font metric and, moreover, we used the
old-style names for ligatures.
The fonts in the OTF format, however, we considered new ones
(note, e.g., that they have Unicode tables and that they are equipped
with the OTF typografic features, both absent from the original
Adobe fonts) and, therefore, following Adobe's recommendations
for the glyph naming in new fonts (see the mentioned by Karl
documentation http://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification
and also Adam Twardoch's John Hudson's comments --
http://typophile.com/node/18452 and
http://typophile.com/node/0 , respectively),
we assigned the new-style ligature names.
In the TeX Gyre Math fonts we also have used the new-style
ligature names.
Two questions:
1. What about using Type 1 fonts for compatibility purposes?
It seems to us taht it could be the simplest patch, provided
the font rendering engines are able to handle conveniently
obsolete Type 1 fonts.
2. Does it make really sense to make a step
backward and revert to the old-style names in the OTF
TeX Gyre fonts (including TeX Gyre Math)? It is feasible,
but we are rather reluctant to introduce such a change,
as it is likely to cause fuss among TeX Gyre users.
Cheers -- Jacko and Piotr
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bogus\l{}aw Jackowski: b_jackow...@gust.org.pl
Hofstadter's Law: It always takes longer than you expect, even
when you take into account Hofstadter's Law.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 6/30/2014 1:15 PM, Boguslaw Jackowski wrote: Norbert: here at Debian recently a problem surfaced with respect to the OpenType TeX Gyre fonts. The problem is that the ligatures are named f_i etc while display engines like poppler, as well as the orginal PostScript fonts, use fi etc. In Debian and Ubuntu, currently the TeX Gyre fonts provide the *standard* postscript fonts, due to be considered generally better. But that means, that at the current moment of one uses the TeX Gyre fonts as a replacement for the PS fonts, the ligatures will not be rendered at all. [...] Related bug reports are: * Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742767 * FreeDesktop: https://bugs.freedesktop.org/show_bug.cgi?id=73291 Dear Colleagues, we are more than happy that the TeX Gyre collection of fonts has been have been chosen as a default font set in Debian distribution. And we are sorry that we haven't predicted the problem of the discrepancy between the new and old ligatures name. Our idea was to provide partially new fonts. More precisely, we have assumed that the fonts in the Type 1 format should be as compatible as possible with the Adobe original fonts. In particular, we tried to preserve (with some exceptions, due to obvious Adobe's bugs) the original font metric and, moreover, we used the old-style names for ligatures. The fonts in the OTF format, however, we considered new ones (note, e.g., that they have Unicode tables and that they are equipped with the OTF typografic features, both absent from the original Adobe fonts) and, therefore, following Adobe's recommendations for the glyph naming in new fonts (see the mentioned by Karl documentation http://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification and also Adam Twardoch's John Hudson's comments -- http://typophile.com/node/18452 and http://typophile.com/node/0 , respectively), we assigned the new-style ligature names. Indeed, so it's f_i etc and using fi for that and foo_bar_whatever for other ligatures makes no sense ... tounicode logic depends on conventions like the _ as ligature separator. In the TeX Gyre Math fonts we also have used the new-style ligature names. Two questions: 1. What about using Type 1 fonts for compatibility purposes? It seems to us taht it could be the simplest patch, provided the font rendering engines are able to handle conveniently obsolete Type 1 fonts. 2. Does it make really sense to make a step backward and revert to the old-style names in the OTF TeX Gyre fonts (including TeX Gyre Math)? It is feasible, but we are rather reluctant to introduce such a change, as it is likely to cause fuss among TeX Gyre users. It makes no sense ... if poppler does something with glyphnames (and i'm not sure why it would) it should deal with it properly and recognize u, uni, index, numbers, _, . ... as classifiers and separators. Dealing with inconsistencies in unicode and fonts is already a pain and adding more confusion makes no sense. btw, If I grep my afm files for f_f and f_l I get lots of hits on linotype fonts like palatino-nova, aldus-nova, palatinosans* so there are type one fonts out there that use _ too. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Dear friends, Am Montag, den 30.06.2014, 13:15 +0200 schrieb Boguslaw Jackowski: we are more than happy that the TeX Gyre collection of fonts has been have been chosen as a default font set in Debian distribution. And we are they are not installed by default, that is. But once they are installed, they take precedence. 1. What about using Type 1 fonts for compatibility purposes? It seems to us taht it could be the simplest patch, provided the font rendering engines are able to handle conveniently obsolete Type 1 fonts. We have chosen to use the OpenType fonts for text rendering, because they are generally considered to be better rendered on screen. 2. Does it make really sense to make a step backward and revert to the old-style names in the OTF TeX Gyre fonts (including TeX Gyre Math)? It is feasible, but we are rather reluctant to introduce such a change, as it is likely to cause fuss among TeX Gyre users. There is a very interesting comment by Miguel Sousa in the second article you posted: In addition to what John wrote, you'll need to have two additional glyphs, named fi and fl, that are duplicates of 'f_i' and 'f_l'. These two additional glyphs should be encoded as FB01 and FB02, respectively. The reason for having to include these glyphs (named and encoded this way) is because they are part of the MacRoman character set. Maybe it will already be sufficient to add those two glyphs. To be honest, these two were the only ones that caught my attention in the sample PDFs provided in the bug reports. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
revert to the old-style names in the OTF Seems like there should be no need to revert. In principle, couldn't the fi ligature glyph appear as both f_i and fi? In other words, add a bunch more duplicate glyphs; nothing else need change, as I understand it ... f + i would still lead to f_i, etc. Ok, it's dumb and ugly, but that's life with computers. karl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On Mon, 30 Jun 2014, Hans Hagen wrote: btw, If I grep my afm files for f_f and f_l I get lots of hits on linotype fonts like palatino-nova, aldus-nova, palatinosans* so there are type one fonts out there that use _ too. Interestingly I cannot trigger the bug with xelatex and Palatino Sans, for example. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On Mon, 30 Jun 2014, Karl Berry wrote: revert to the old-style names in the OTF Seems like there should be no need to revert. In principle, couldn't Agreed, reverting is bad. the fi ligature glyph appear as both f_i and fi? In other words, That would be the safest option, indeed. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Dear Jacko, thanks for your answer and time The fonts in the OTF format, however, we considered new ones (note, e.g., that they have Unicode tables and that they are equipped with the OTF typografic features, both absent from the original Adobe fonts) and, therefore, following Adobe's recommendations for the glyph naming in new fonts (see the mentioned by Karl Agreed. 2. Does it make really sense to make a step backward and revert to the old-style names in the OTF No. I disagree here. Poppler should be fixed. TeX Gyre fonts (including TeX Gyre Math)? It is feasible, but we are rather reluctant to introduce such a change, Indeed, and I do *not* want you to make this step. As Kalr pointed out, either we leave it like it is now, and get poppler do be reasonable, or adding another fake glyph fi/f_i, but not changing names, this is not a good idea. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/1/2014 1:05 AM, Norbert Preining wrote: On Mon, 30 Jun 2014, Hans Hagen wrote: btw, If I grep my afm files for f_f and f_l I get lots of hits on linotype fonts like palatino-nova, aldus-nova, palatinosans* so there are type one fonts out there that use _ too. Interestingly I cannot trigger the bug with xelatex and Palatino Sans, for example. If I understand right, the bug has to do with viewing (rendering) a glyph in a pdf file. In pdf the page stream has numbers pointing to a (normally) subset index which in turn maps onto the font slots (can be any order). Normally no glyph name is involved in that. Those names might kick in when copying is involved and no tounicode mapping is present in the pdf. As you mention in a previous mail, it's a bug in poppler (or maybe some library it uses) that somehow used glyph names. I agree that there is no need to change the font (and I cannot predict what other issues might show up by duplicating glyph names; for instance turning f + i into an fi glyph .. it would still map onto the one associated with f_i). Using the unicode ligature sis a bad idea anyway as all these ligs in unicode make not much sense and is just there to suit bad old times. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On Fri, 27 Jun 2014, Karl Berry wrote: See section 6 (or search for ligature) in http://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification Thanks, I forwarded this to the poppler group - I am not very optimistic that they will do anything in this direction, but we should try at least ;-) Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
The problem is that the ligatures are named f_i Adobe wants it that way these days, as I understand it. (Personally I think they were terribly wrong to try to change something so fundamental but, surprisingly, they didn't ask me. :) See section 6 (or search for ligature) in http://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification (and probably other adobe documents too, that's just what I found first). In practice, since rendering software is so random about it, perhaps fonts should include ligatures under both names. Sigh. karl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Dear good friends from Poland, here at Debian recently a problem surfaced with respect to the OpenType TeX Gyre fonts. The problem is that the ligatures are named f_i etc while display engines like poppler, as well as the orginal PostScript fonts, use fi etc. In Debian and Ubuntu, currently the TeX Gyre fonts provide the *standard* postscript fonts, due to be considered generally better. But that means, that at the current moment of one uses the TeX Gyre fonts as a replacement for the PS fonts, the ligatures will not be rendered at all. This was not the case originally, when we introduced that, but after some poppler upgrade the ligatures f_i etc are not accepted anymore. Related bug reports are: * Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742767 * FreeDesktop: https://bugs.freedesktop.org/show_bug.cgi?id=73291 Unfortunately the poppler maintainers do not seem to like to add additional variants to be checked. In the Debian bug report a renaming of glyph fontforge script has been suggested, but trying that resulted in a very different fonts (at least from the table sizes and total font size), so I am very reluctant to use this script. (See below for the core part) Do you have any suggestion concerning this unfortunate situation? I see a few options at the moment: * Adapting the fonts from your side. This would be my preferred way, of course. But since I don't know any further implications, I cannot decide on that. * Adapting the fonts on the Debian side: I don't want to do this, since we would have different fonts then the rest of the world, and that is not good. * Dropping TeX Gyre as substitute for the PS fonts: The simplest option, but would hemper font quality rendering in many projects. I would be very grateful if you could let me know your opinion. All the best Norbert fontforge script core part: Select(0xFB00) SetGlyphName(ff) Select(0xFB01) SetGlyphName(fi) Select(0xFB02) SetGlyphName(fl) Select(0xFB03) SetGlyphName(ffi) Select(0xFB04) SetGlyphName(ffl) PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
