<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Enumerate PDF named destinations" href="https://bugs.freedesktop.org/show_bug.cgi?id=97262#c39">Comment # 39</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Enumerate PDF named destinations" href="https://bugs.freedesktop.org/show_bug.cgi?id=97262">bug 97262</a> from <a class="email" href="mailto:trueroad@trueroad.jp" title="Masamichi Hosoda <trueroad@trueroad.jp>"> Masamichi Hosoda</a> <pre>(In reply to Adrian Johnson from <a href="show_bug.cgi?id=97262#c35">comment #35</a>) > Ok leave it as two separate sets of functions. > > In the longer term I would like to read all the names into a map or hash. > The current implementation that reads the nameTree (which should already be > sorted except for when it isn't) then runs qsort on it is not ideal. But > that can be the topic of another bug. Thank you. I've updated core patches (v2-0001, v2-0002, v2-0003). > > However, unfortunately, if the name contains \0, > > poppler_document_find_dest() cannot find it. > > If you escape the \0 as per <a href="show_bug.cgi?id=97262#c33">comment 33</a> it should work. I'd like GBytes instead of escape. I'd like to add something like the following function. PopplerDest *poppler_document_find_dest_bytes (PopplerDocument*, const GBytes); > > Almost UTF-16 strings contains \0. > > Isn't the glib API UTF-8 based? Even if the glib API is UTF-8 based, PDFs can contain UTF-16. Moreover, if I understand correctly, encoding of the PDF destination names has not been defined. It can contain UTF-16 and PDFDocEncoding. Also it can even contain pure binaries.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>