GNOME Bugzilla – Bug 695977
Zapfino typface (font) not correctly rendered
Last modified: 2018-05-22 13:08:23 UTC
Created attachment 239039 [details] How it should look I opened a ticket here for WeasyPrint, but apparently the issue is in fact due to Pango: https://github.com/Kozea/WeasyPrint/issues/50 In case that ticket disappears for some reason, here is what it said: 'On OS X 10.6.8, Firefox, TextEdit and others render the word "Zapfino" in the typeface Zapfino as in the first attached image. However, WeasyPrint renders it as in the second attached image. My understanding is that in this particular case, Firefox, TextEdit, etc, are honouring Zapf's intentions, and that WeasyPrint is not.' I'm unsure exactly which version(s) or part(s) of Pango are being called by WeasyPrint on this Mac. The dependencies for WeasyPrint were installed using the instructions here for MacPorts: http://weasyprint.org/docs/install/ . It may be useful to know that on this Mac, "$ pango-view --version" produces: pango-view (pango) 1.32.5 Pango module interface version: 1.8.0 and "$ pango-querymodules --version" produces: pango-querymodules (pango) 1.32.5 module interface version: 1.8.0 and on that basis, I have tentatively selected "1.32.x" in the "Version" box for this bug report. On the basis that cairo is one of the dependencies for WeasyPrint, I have tentatively selected "cairo" in the "Component" box for this bug report.
Created attachment 239040 [details] How WeasyPrint renders it
Having read a little more, and given a bit more thought to Simon Sapin's reply to the bug report I filed on GitHub, I realise the relevant component is probably not cairo, but more likely pango-view.
I wonder whether the problem is that the AAT tables for Zapfino have the fancy ligature but the OpenType tables don't. Indeed, I checked that: 1. Using the CoreText backend in HarfBuzz makes it produce the same ligature. You can do this (if your HarfBuzz was compiled with the CoreText backend enabled) by setting HB_SHAPER_LIST=coretext env var, 2. Checking the OpenType tables in the font, no substitution produces the 'Z_a_p_f_i_n_o' ligature. One day we'll either have native AAT support in HarfBuzz, or make it use CoreText by default if the font has morx tables. But in general, this is not quite a bug in HarfBuzz as is.
Thank you for looking into this. Just so you know where I'm coming from: I'm a total novice in relation to this stuff. When I opened this ticket, I had not heard of HarfBuzz, nor CoreText, nor morx. Now, owing to your reply, I have heard of them; but I have not yet had time to learn much at all about them. (I have added your essay at http://behdad.org/text/ to my reading list, however.) I see that, from your perspective as a developer, this is "not quite a bug in HarfBuzz" and that you have marked my ticket as "resolved". From my perspective as a user, though, I am unsure how to proceed. I do not know for sure if my HarfBuzz was compiled with the CoreText backend enabled, because I did not compile it myself: it was simply installed as a dependency by MacPorts. However, I ran `HB_SHAPER_LIST=coretext ; export HB_SHAPER_LIST` and then re-ran WeasyPrint to generate a PDF from HTML. As viewed in Preview.app, the Zapfino logo came out correctly in the resulting PDF, but the rest of the text looked mangled. I will attach screenshots of both the HTML as rendered in Firefox, and of the same part of the document as rendered in the PDF.
Created attachment 239255 [details] How the HTML looks in Firefox with HB_SHAPER_LIST=coretext
Created attachment 239256 [details] How the PDF generated from that HTML by WeasyPrint, with HB_SHAPER_LIST=coretext, looks in Preview.app
I realise Firefox probably isn't using the MacPorts HarfBuzz, which is why Firefox's rendering was unaffected by the change to the env var. But the fact that Firefox is able to render both the Zapfino logo *and* the rest of the text correctly makes me wonder why WeasyPrint seems only to be able to render either the Zapfino logo *or* the rest of the text correctly, but not both.
That doesn't look right. Do you know which font that is? I have suspicions for what may be going on.
Reopening for now.
The text that ended up garbled was marked up to use Verdana.
I think this should be resolved in bug 738505.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/217.