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.