On Mar 5, 2010, at 12:46 PM, Krzysztof Kosiński wrote:
We are still using the internal Poppler API to import PDFs. This is
very bad, since the internal Poppler API is not stable, and will keep
breaking. (We already don't build with poppler > 0.12.1)
How about using the public Glib API to render to a Cairo SVG surface
instead? This is how pdf2svg works, and to be honest I had to use that
utility several times to augment Inkscape, because it handles text
much better. What are the advantages to using internal Poppler API
directly?
You should try skimming our archives to see what has been discussed in the past.
Personally I dislike using internal hooks, but I do know the Cairo SVG surface gave us
very poor quality results for what we want. Not that it looked bad, per se, but more that
the structure of the resulting data was poor for editing and for source.
Among other things we've discussed this with other projects and with the Poppler
people themselves. They agreed that the standard public APIs did not match what we as an
editor would need. So they've started on crafting a new standard API that we and other
projects including some Qt can also leverage.
Probably the best thing to help with at this point would be to come up with some test case
files and usage scenarios so we can make sure the new API will give us all the hooks we
need. Off the top of my head I can think of documents with mixed CMYK and RGB, color
profiles, embedded fonts, metadata, etc. as all needing to be handled well.