[win32] EPS/PS/PDF export of text objects problematic with 0.47(pre)

[~suv-2]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[kaver-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[~suv-2]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[J.B.C.Engelen]

> -----Original Message-----
> From: kaver [mailto:kaver@...]
> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alexandre Prokoudine]

On Tue, Nov 3, 2009 at 12:00 AM, ~suv wrote:

> How critical is (especially) PDF export for Inkscape 0.47 on win32
> platforms?

0.47 does not deserve being released with broken PDF export.

Alexandre

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Jon M]

> 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




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[~suv-2]

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 ]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Jon M]

> 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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[~suv-2]

[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>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Krzysztof Kosiński]

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

[pdf-export-fix.patch]

---

Index: src/extension/internal/cairo-render-context.cpp
===================================================================
--- src/extension/internal/cairo-render-context.cpp (revision 22560)
+++ src/extension/internal/cairo-render-context.cpp (working copy)
@@ -1458,7 +1458,7 @@
 #define GLYPH_ARRAY_SIZE 64
 
 unsigned int
-CairoRenderContext::_showGlyphs(cairo_t *cr, PangoFont *font, std::vector<CairoGlyphInfo> const &glyphtext, bool is_stroke)
+CairoRenderContext::_showGlyphs(cairo_t *cr, PangoFont *font, std::vector<CairoGlyphInfo> const &glyphtext, bool path)
 {
     cairo_glyph_t glyph_array[GLYPH_ARRAY_SIZE];
     cairo_glyph_t *glyphs = glyph_array;
@@ -1482,15 +1482,10 @@
         i++;
     }
 
-    if (is_stroke) {
+    if (path) {
         cairo_glyph_path(cr, glyphs, num_glyphs - num_invalid_glyphs);
     } else {
-        if (_is_texttopath) {
-            cairo_glyph_path(cr, glyphs, num_glyphs - num_invalid_glyphs);
-            cairo_fill_preserve(cr);
-        } else {
-            cairo_show_glyphs(cr, glyphs, num_glyphs - num_invalid_glyphs);
-        }
+        cairo_show_glyphs(cr, glyphs, num_glyphs - num_invalid_glyphs);
     }
 
     if (num_glyphs > GLYPH_ARRAY_SIZE)
@@ -1552,20 +1547,30 @@
             _showGlyphs(_cr, font, glyphtext, TRUE);
         }
     } else {
-
+        bool fill = false, stroke = false, have_path = false;
         if (style->fill.isColor() || style->fill.isPaintserver()) {
             // set fill style
             _setFillStyle(style, NULL);
-
-            _showGlyphs(_cr, font, glyphtext, FALSE);
+            fill = true;
         }
 
         if (style->stroke.isColor() || style->stroke.isPaintserver()) {
             // set stroke style
             _setStrokeStyle(style, NULL);
-
-            // paint stroke
-            _showGlyphs(_cr, font, glyphtext, TRUE);
+            stroke = true;
+        }
+        if (fill) {
+            if (_is_texttopath) {
+                _showGlyphs(_cr, font, glyphtext, true);
+                have_path = true;
+                if (stroke) cairo_fill_preserve(_cr);
+                else cairo_fill(_cr);
+            } else {
+                _showGlyphs(_cr, font, glyphtext, false);
+            }
+        }
+        if (stroke) {
+            if (!have_path) _showGlyphs(_cr, font, glyphtext, true);
             cairo_stroke(_cr);
         }
     }
Index: src/style.cpp
===================================================================
--- src/style.cpp (revision 22560)
+++ src/style.cpp (working copy)
@@ -2684,7 +2684,7 @@
 
     style->stroke_width.set = FALSE;
     style->stroke_width.unit = SP_CSS_UNIT_NONE;
-    style->stroke_width.computed = 1.0;
+    style->stroke_width.computed = 0.0;
 
     style->stroke_linecap.set = FALSE;
     style->stroke_linecap.value = style->stroke_linecap.computed = SP_STROKE_LINECAP_BUTT;

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[~suv-2]

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

--
~suv

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[bulia byak]

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?

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Joshua A. Andler-2]

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


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Nicolas Dufour-5]

> De : Joshua A. Andler <scislac@...>
> 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



     

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Krzysztof Kosiński]

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel