<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Umlaut conversion error for Type1 fonts in WinAscii Encoding"
href="https://bugs.freedesktop.org/show_bug.cgi?id=70364">70364</a>
</td>
</tr>
<tr>
<th>Assignee</th>
<td>ajohnson@redneon.com
</td>
</tr>
<tr>
<th>Summary</th>
<td>Umlaut conversion error for Type1 fonts in WinAscii Encoding
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>cairo-bugs@cairographics.org
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Reporter</th>
<td>winter@bfw-online.de
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86 (IA32)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Component</th>
<td>postscript backend
</td>
</tr>
<tr>
<th>Product</th>
<td>cairo
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=87422" name="attach_87422" title="Input document which is printed incorrectly">attachment 87422</a> <a href="attachment.cgi?id=87422&action=edit" title="Input document which is printed incorrectly">[details]</a></span>
Input document which is printed incorrectly
Hi,
when printing (or running the print preview of) the attached PDF with evince
(utilizing the PostScript backend of Cairo of course), the umlauts (like รถ) are
lost. The fonts used in the PDF are not embedded, the PDF seems to be encoded
in a Windows charset and the resulting PostScript seems to include the combined
characters for umlauts like 'odieresis', however it cannot render them hinting
the possibility it is a combined glyph made up of 'o' and 'dieresis' and one of
those might be missing. However my tries to manually include 'dieresis' in the
resulting type1 font subset dict were futile.
Also probably noteworthy but not relevant to this bug is the fact that xpdf
crashes when one tries to open the PDF, which suggests it might by a "strange"
PDF.
My approach of including 'dieresis' in the dictionary was (patched against
cairo-1.12.16 of Debian, the git log of the file seemed to suggest there were
no later patches to the file after the Debian release):
diff --git a/src/cairo-type1-subset.c b/src/cairo-type1-subset.c
index 4b64403..dfcd1a1 100644
--- a/src/cairo-type1-subset.c
+++ b/src/cairo-type1-subset.c
@@ -1407,6 +1407,15 @@ skip_subrs:
cairo_type1_font_subset_use_glyph (font, index);
}
+ for (i = 0; i < font->base.num_glyphs; i++) if (font->glyph_names[i])
+ { fprintf (stderr, "glyph: %s\n", font->glyph_names[i]);
+ if (!strcmp (font->glyph_names[i], "dieresis")
+ || !strcmp (font->glyph_names[i], "odieresis") || !strcmp
(font->glyph_names[i], "o"))
+ { cairo_type1_font_subset_use_glyph (font, i);
+ fprintf (stderr, "-----> added\n");
+ }
+ }
+
/* Go through the charstring of each glyph in use, get the glyph
* width and figure out which extra glyphs may be required by the
* seac operator (which may cause font->num_glyphs to increase
Best regards,
Leon</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>