[win32] EPS/PS/PDF export of text objects problematic with 0.47(pre)
The combination of these bugs:
[Bug 469180] https://bugs.launchpad.net/bugs/469180 Significant Differences in exported PDF File Size from 0.46 to 0.47pre3/4 [Bug 388257] https://bugs.launchpad.net/bugs/388257 Inkscape 0.47Pre: PDF/PS Export 'Text to Paths' gives inconsistent results [Bug 271695] https://bugs.launchpad.net/bugs/271695 Kerned text embeds too many fonts and blows up the file size in EPS/PS (special case of bug #469180, could potentially cause invalid PDF files if bug #431314 turns out to be a duplicate)
leaves Inkscape 0.47(pre) users on win32 platforms with few options to export SVG documents containing text to good quality PDF files with reasonable file sizes.
a) text as text: font embedding bug in cairo-win32 blows up file size disproportionally due to unnecessary embedding of fonts. Multiple uses of the same font are not merged into the same subset. b) text to path: the broken export option results in bad quality and huge file size due to text paths being exported multiple times and drawn on top of each other.
The only way left at the moment: c) object to path: convert all text objects with the menu command 'Path > Object to Path' before saving as EPS/PS/PDF.
How critical is (especially) PDF export for Inkscape 0.47 on win32 platforms?
~suv
suv, What about d) using a PDF printer driver?
I may be missing something here but I would think that in real life PDF export for Inkscape on win32 platforms would not be critical. Win users have any number of free PDF printers which do an excellent job with Inkscape in its current version. My favourite at the moment is PrimoPDF and it gave a pdf of 10KB with sample2.svg and 0.47pre4 using either screen or print quality.
kaver
Original Message -----
The only way left at the moment: c) object to path: convert all text objects with the menu command 'Path > Object to Path' before saving as EPS/PS/PDF.
How critical is (especially) PDF export for Inkscape 0.47 on win32 platforms?
~suv
On 3/11/09 11:44, kaver wrote:
What about d) using a PDF printer driver?
If it works fine with every Inkscape installation this is certainly a viable workaround. I can't test it because I don't use Windows myself. The file size of your attached samples is almost 10 times smaller than the one exported with Inkscape 0.47pre3 (attached to bug #469180) and even somewhat smaller than the one created with Inkscape 0.46.
It might however not be applicable when using Inkscape on the commandline or in scripts (as the reporter of bug #469180 does and depends on)?
I may be missing something here but I would think that in real life PDF export for Inkscape on win32 platforms would not be critical.
My question was more towards the 'marketing' of Inkscape as a cross-platform tool that fully supports exchange with other vector format like PDF and PS. (And since I spent some time now with bug triage I am anticipating a lot of bug reports once Inkscape 0.47 is out and produces PDFs on win32 that are huge compared to the same files exported with Inkscape 0.46). But maybe I 'underestimate' the flexibility of Inkscape users on win32 platforms - that's why I asked for feedback ;-)
~suv
My question was more towards the 'marketing' of Inkscape as a cross-platform tool that fully supports exchange with other vector format like PDF and PS. (And since I spent some time now with bug triage I am anticipating a lot of bug reports once Inkscape 0.47 is out and produces PDFs on win32 that are huge compared to the same files exported with Inkscape 0.46). But maybe I 'underestimate' the flexibility of Inkscape users on win32 platforms - that's why I asked for feedback ;-)
As an Inkscape on Windows user, my preferences...
* Ensure the cross-platform tool and exchange with other vector formats memes continue to be a high priority * Keep the quality of the PDF high even if (in the short term) the exported file size is large * Don't make me remember some hacky 'Path > Object to Path' before saving as EPS/PS/PDF workaround that goes away when you fix things. This is much uglier marketing wise than a short term file size issue in my opinion. * Don't let the fix continually slide out because of "higher priorities" * Don't let this become a blocking issue for 0.47 release
Yes, you'll likely get more bug reports filed, but maybe fewer than you think. If not, it just keeps you motivated to get rid of the issue ;)
Great job, and a big THANKS!
Jon
Adding some numbers to illustrate my concerns (it's not about the number of expected bug reports but the number of frustrated users...)
On 3/11/09 23:18, Jon wrote:
- Keep the quality of the PDF high even if (in the short term) the
exported file size is large
bug #271695: 632 KB (osx) vs. 24 MB (win32) (EPS export)
bug #431314: 80 KB (osx) vs. 3.8 MB (win32) (PDF export) (and this is only a reduced case of a one-page-document, the original file doesn't even get exported on win32)
- Don't make me remember some hacky 'Path > Object to Path' before
saving as EPS/PS/PDF workaround that goes away when you fix things. This is much uglier marketing wise than a short term file size issue in my opinion.
Without applying this 'hack' when using the current 0.47pre version you get *both* bad text/font quality and even bigger file size when exporting with the 'Convert texts to paths' option:
bug #271695: 2.7 MB (0.46) vs. 411 MB (0.47pre3) (EPS export) (but with lower text/font quality due to bug #388257)
~suv
[ note: for the font embedding issue I don't have comparable file size numbers of exports on linux platforms available ]
Adding some numbers to illustrate my concerns (it's not about the number of expected bug reports but the number of frustrated users...)
By frustration, do you mean you expect them to complain about large file sizes or do you mean they'll complain about large file sizes potentially causing other problems like out of memory, etc?
For me, I'd still be OK will being frustrated in the short term with large files sizes if their downstream effect wasn't to crash my system or other nasty effects. My primary concerns are to keep the quality and keep my system stable. I'll deal with file sizes for the short term. I hope I'm representative of other Windows users and not leading you down the wrong path.
On 3/11/09 23:18, Jon wrote:
- Keep the quality of the PDF high even if (in the short term) the
exported file size is large
bug #271695: 632 KB (osx) vs. 24 MB (win32) (EPS export)
bug #431314: 80 KB (osx) vs. 3.8 MB (win32) (PDF export) (and this is only a reduced case of a one-page-document, the original file doesn't even get exported on win32)
I better see your concern. I'm going to test more PDF exports on my Vista w/0.47pre4 today.
- Don't make me remember some hacky 'Path > Object to Path' before
saving as EPS/PS/PDF workaround that goes away when you fix things. This is much uglier marketing wise than a short term file size issue in my opinion.
Without applying this 'hack' when using the current 0.47pre version you get *both* bad text/font quality and even bigger file size when exporting with the 'Convert texts to paths' option:
bug #271695: 2.7 MB (0.46) vs. 411 MB (0.47pre3) (EPS export) (but with lower text/font quality due to bug #388257)
Yikes.
I almost hate to even suggest this idea as the downstream impacts may be horrible, but that said, is is possible to hard-code your best pragmatic (high text/font quality) workaround into the "save as EPS/PS/PDF code path" *only* for Windows systems to limit the exposure and only until you can do a point release fix?
How close (time wise) do you feel you are in determining true root cause and implementing a tested fix?
Jon
-----Original Message----- From: kaver [mailto:kaver@...1960...] Sent: Tuesday, November 03, 2009 11:45 To: ~suv; Inkscape Devel List Subject: Re: [Inkscape-devel] [win32] EPS/PS/PDF export of textobjectsproblematic with 0.47(pre)
suv, What about d) using a PDF printer driver?
I may be missing something here but I would think that in real life PDF export for Inkscape on win32 platforms would not be critical.
For all users that I know, PDF export (and import btw) is key. Printing to a PDF printer is not a solution (I just tried, and it lacks options that I need). I have not checked the exact problem we have now, but if the PDF output is much poorer than 0.46, it will be a reason for me not even telling my colleagues that there is a new Inkscape version. (perhaps too dramatic, but true; from what I read, the issue is with fonts and file sizes, so probably not so bad)
-Johan
[update]
A) cairo font embedding bug (win32) https://bugs.launchpad.net/bugs/469180 https://bugs.launchpad.net/bugs/271695
On 5/11/09 09:37, Adrian Johnson wrote:
I written a patch for cairo to fix this. I've put the patch and cairo/pixman dlls built with the patch here:
http://people.freedesktop.org/~ajohnson/bug271695/
I still need to do further testing with the patch.
AFAIU the cairo patch only concerns the win32 packaging process (i.e. updating Cairo in the Dev Libraries repository).
B) 'Convert texts to paths' export option https://bugs.launchpad.net/bugs/388257
On 3/11/09 19:31, ivan louette wrote:
The problem only occurs with filled text without outline. No problem for me with only outline text or text with fill and outline.
I verified that keeping the text stroke style attributes by setting a stroke fill color and stroke-width to '0.00' px does not trigger the bug: Inkscape 0.46+devel r22552 then creates PDFs of the same quality and file size as Inkscape 0.46.
Could this be related to the changes described in the release notes as 'Optimized CSS properties'[1]?
There is no patch available and the bug happens on all platforms.
~suv
[1] http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Optimized_CSS_properties
Please check whether the attached patch fixes the issue (for me it does, at least for the testcase at Launchpad). It's also attached to the LP bug.
It seems that cairo_restore does not clear the path in extension/internal/cairo-render-context.cpp, function renderGlyphtext. When text has fill but no stroke and text to path is active, only cairo_fill_preserve is called. This causes an accumulation of text paths observed in exported PDFs.
BTW, I noted that the ellipse prefs fix isn't committed yet. Could a release warden commit it? I posted it here somewhere, as well as here: https://bugs.launchpad.net/inkscape/+bug/459811
Regards, Krzysztof
On 7/11/09 01:20, Krzysztof Kosiński wrote:
Please check whether the attached patch fixes the issue (for me it does, at least for the testcase at Launchpad). It's also attached to the LP bug.
It seems that cairo_restore does not clear the path in extension/internal/cairo-render-context.cpp, function renderGlyphtext. When text has fill but no stroke and text to path is active, only cairo_fill_preserve is called. This causes an accumulation of text paths observed in exported PDFs.
[Bug 388257] https://bugs.launchpad.net/bugs/388257: patch tested and fix confirmed with Inkscape 0.46+devel r22557+patch on OS X 10.5.8 with several test cases attached to the LP bug report and local SVG files with multiline text objects and varying fonts.
Thank you Krzysztof! Any chance this gets into 0.47?
BTW, I noted that the ellipse prefs fix isn't committed yet. Could a release warden commit it? I posted it here somewhere, as well as here: https://bugs.launchpad.net/inkscape/+bug/459811
ditto
Thanks Krzysztof, both your patches are tested and applied.
Any more patches to consider before the release? If there are none, why don't we go ahead and release this coming week?
On Sat, 2009-11-07 at 20:53 -0400, bulia byak wrote:
Thanks Krzysztof, both your patches are tested and applied.
Any more patches to consider before the release? If there are none, why don't we go ahead and release this coming week?
I have a couple patches I am about to commit. Let's lock down on Monday morning, once a branch is tagged, the packagers can get to work and hopefully we can do the release on Friday! Woohoo!
Cheers, Josh
De : Joshua A. Andler <scislac@...400...> I have a couple patches I am about to commit. Let's lock down on Monday morning, once a branch is tagged, the packagers can get to work and hopefully we can do the release on Friday! Woohoo!
Great news!
Don't forget to disable the View>Scripts menu (if not fixed meanwhile). [Bug 346721] Segfault after opening JVM scripts dialog https://bugs.launchpad.net/inkscape/+bug/346721
Regards, -- Nicolas
Please also commit the follow-up to the PDF export bug. I put the style setting in wrong places, and when both fill and stroke was set on text, one overwrote the other. I forgot to test that case, fortunately ~suv caught it soon enough.
https://bugs.launchpad.net/inkscape/+bug/388257
Regards, Krzysztof
participants (9)
-
unknown＠example.com -
Alexandre Prokoudine -
bulia byak -
Jon -
Joshua A. Andler -
kaver -
Krzysztof Kosiński -
Nicolas Dufour -
~suv