I have this problem too, even after a clean build. Luca

Anyway, I added #include <libxml/parser.h> in rev 9776, see if this fixes it for you.

W dniu 22 września 2010 16:07 użytkownik bulia byak <buliabyak@...400...> napisał:

...

i get the following error: Make error line 299: problem compiling: src/xml/repr-io.cpp: In function 'Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*)': src/xml/repr-io.cpp:297: error: 'XML_PARSE_HUGE' was not declared in this scope

That was my change - sorry for that. Krzysztof, why can this be not defined in libxml from Windows devlibs, even though it works on Linux? I don't have Windows right now to test.

Looks like the libxml2 version in devlibs (2.6.30) is too old to know about it. I will update it once I get home today.

BTW, can Inkscape really handle text nodes larger than 10MB? I think we would run out of address space on a 32bit system before we could display such a long text.

Regards, Krzysztof

2010/9/23 bulia byak <buliabyak@...400...>:

The reported bug which PARSE_HUGE fixes was not about text node sizes, but about depth of recursion which was limited to 256. Some PDF files produce deeper grouping than that when imported into Inkscape. Which may be caused by a bug in Poppler, but in any case this sounds like an unreasonable limit to me.

OK, sounds good.

Also worth investigating is whether using poppler-glib to draw to a Cairo SVG surface and then postprocessing the output (e.g. remove excess grouping) produces better results than using internal Poppler APIs directly. For me, the poppler-glib + Cairo route works better when importing certain PDFs - I have attached one of them. The current way will not import atom labels, while using pdf2svg (which uses the route mentioned above) works correctly; the result of pdf2svg conversion is attached as hpesw.svg.

Regards, Krzysztof