<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - FreeText annotation ignores font" href="https://bugs.freedesktop.org/show_bug.cgi?id=81748#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - FreeText annotation ignores font" href="https://bugs.freedesktop.org/show_bug.cgi?id=81748">bug 81748</a> from <a class="email" href="mailto:haxtibal@posteo.de" title="Tobias Deiminger <haxtibal@posteo.de>"> Tobias Deiminger</a> <pre>Thanks Oliver! I've got another patch pending based on yours. It already works somewhat. But there's something to clarify ahead: <a href="attachment.cgi?id=103449" name="attach_103449" title="Annotation example">Attachment 103449</a> <a href="attachment.cgi?id=103449&action=edit" title="Annotation example">[details]</a> seems broken. If that's true we can't use it as reference. Annot /DA has a Tf operand '/Rufscript'. << % ... /DA (/Rufscript 18 Tf 0 0 0.5 rg ) /Subtype /FreeText >> But there's no resource named '/Rufscript' in the font entry of the default resource dictionary. More over, there's no default resource dictionary at all: 3 0 obj % This is "Interactive Form Dictionary", aka AcroForm << % There's no /DR (default resource dictionary) in here! /Fields [ 5 0 R ] /SigFlags 3 >> endobj Obviously the PDF composer (prawnpdf [0]) thought it would be sufficient to write the name of the font as Tf operand. But that's not true. You need to name a font resource entry as operand, not the name of a font itself. The font entry can have an arbitrary name. It's /BaseFont in font dictionary which decides what font program to use. Some standard excerpts that make me believe I'm right: PDF 32000-1:2008 12.5.6.6 Free Text Annotations: "The default appearance string that shall be used in formatting the text (see 12.7.3.3, “Variable Text”)" PDF 32000-1:2008 12.7.3.3 Variable Text: "The specified font value shall match a resource name in the Font entry of the default resource dictionary" I checked the output of LaTex pdfcomment package [1] and found it misbehaves in a similar way to <a href="attachment.cgi?id=103449" name="attach_103449" title="Annotation example">attachment 103449</a> <a href="attachment.cgi?id=103449&action=edit" title="Annotation example">[details]</a>. Two different composers misbehaving leaves me in doubt if I'm right about the non conformance. Phil says Adobe Reader shows the right font. That's not true for me. When I open <a href="attachment.cgi?id=103449" name="attach_103449" title="Annotation example">attachment 103449</a> <a href="attachment.cgi?id=103449&action=edit" title="Annotation example">[details]</a> in Adobe Reader 10, they show a fallback font instead of Rufscript. Can anyone confirm this? To go on we have to clarify: - Is it really out-of-spec if we don't find DAs font tag in the default resource font dictionary, or is it just me misunderstanding the standard? - If it is really out-of-spec, shall we consider some heuristics to search the best font anyway? E.g. search in other resource dictionaries then the default one (e.g. page resource dictionaries), or use font tag as /BaseFont. - Or shall we be strict, use some simple default logic in poppler and tell folks at [0] and [1] about their bug? [0] <a href="https://github.com/prawnpdf/prawn">https://github.com/prawnpdf/prawn</a> [1] <a href="https://bitbucket.org/kleberj/pdfcomment/wiki/Home">https://bitbucket.org/kleberj/pdfcomment/wiki/Home</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>