[Poppler-bugs] [Bug 97262] Enumerate PDF named destinations

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=97262

--- Comment #35 from Adrian Johnson <ajohnson at redneon.com> ---
(In reply to Masamichi Hosoda from comment #31)
> > Internally, the functions should combine the Name Tree dests and dict dests
> > into one list.
> 
> Name Tree is recorded in Catalog::destNameTree.
> It has GooString for its name.
> So getDestName() can return the pointer of GooString.
> The return value should not be deleted.
> 
> Dests Dict is recoded in Catalog::dests.
> However, it does not have GooString for its name.
> It has only char* for its name.
> So getDestName() have to construct GooString from char*.
> The return value should be deleted.

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.

> > 1) A list of just the names. The user can use poppler_document_find_dest()
> > to get the dests.
> 
> Is is something like
> GList *poppler_document_build_dests_namelist()
> ?
> It returns the pointer of GList which contains GBytes for destination name.
> If you would like it, I'll create a patch.
> 
> However, unfortunately, if the name contains \0,
> poppler_document_find_dest() cannot find it.

If you escape the \0 as per comment 33 it should work.

> 
> > or
> > 2) A binary tree of names and dests. This has the advantage that iterating
> > the names is in alphabetical order instead of the the random order of the
> > hash table.
> 
> I'd like this.

Carlos, do you have an opinion on whether to return a GList of names or binary
tree of names/LinkDests?

> Almost UTF-16 strings contains \0.

Isn't the glib API UTF-8 based?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/poppler-bugs/attachments/20160901/0bcb1acb/attachment.html>