<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#c5">Comment # 5</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:aacid@kde.org" title="Albert Astals Cid <aacid@kde.org>"> Albert Astals Cid</a> <pre>(In reply to Tobias Deiminger from <a href="show_bug.cgi?id=81748#c3">comment #3</a>) > 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? What you're describing seems like what i fixed in <a href="https://cgit.freedesktop.org/poppler/poppler/commit/?id=8821c04f36cb737776cd9077a46f1a9f86ca54e7">https://cgit.freedesktop.org/poppler/poppler/commit/?id=8821c04f36cb737776cd9077a46f1a9f86ca54e7</a> but not sure if that patch helps for non Forms, maybe not, but you could get inspired by it?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>