Inkscape 0.47Pre: PDF/PS Export 'Text to Paths' gives inconsistent results

Confirmed with Inkscape 0.47pre0-1, OS X 10.5.7

- exporting text as path
I get the same result: the rendering of the cloned text changes on each line from rather pixellated to almost antialiased. Recreating the text without clones or transforms produces the same result.

- exporting text as text
via 'Save as...' the antialiasing and file sizes are ok as expected. I get the same result when using 'Print...' > 'Preview'. The resulting pdf file size is 7'764 bytes, even smaller as your 'test.46.pdf' file.

Your other test files were text-only as well or did you see the same rendering effect with different objects - besides the increased file size?

The rendering problem seems to be limited only to text exported as a path. I tried several of my files, some path only, some mixed path and text. Other improvements in export like masks and rendering filter effects are working great.

Confirmed with Inkscape 0.47pre0-1, on Ubuntu linux 9.04

But in addition, exporting text as path draw outline text instead of plain text !

Here is the svg file :

and the PDF file.

In my opinion, this bug must be resolved before the 0.47 release

@skam,
looking at the svg src - you have a clip path applied to the text?
Did you test if it has an influence on the pdf output?

Pdf output on my system looks different - but I don't have your font
installed. Converted to path, the text isn't rendered outlined in the
pdf file. Can you try with a different font?

Or maybe you could make a less complex test case - that makes it easier
to narrow down the problem... ?

@~suv

The font is "Fontin Sans", you can find it here : http://www.josbuivenga.demon.nl/fontinsans.html
I have tested deleting all clip, and the result is different... No outline, but the text become black and is bad draw.
Using Bitstream Vera Sans instead of Fontin Sans it's the same result :

Here the svg

and the PDF file

Thanks for your attention

I get the same results as you now:

1) with Fontin Sans installed (otf font), text is converted to an outlined path
2) ...-noclip.svg with Bitstream Vera Sans: produces very pixellated pdf output.

I don't have other otf fonts on my system, so ATM I cannot compare how pango/cairo handle other fonts in this format. On OS X pango has (had?) issues with fonts in dfont and other (apple) font formats.

Without clipping, the results look similarly bad as described above by ezrakatz.

Another test case: the pixelated text output quality in PDF depends on
the sequence of the SVG elements in the SVG file, at least when viewing
the PDF file with 'Preview' on OS X. Can you confirm that the issue is
independent of the PDF viewer (Adobe, evince,… )?

Save the attached file as PDF with
a) keep text as text
b) convert text to path
and compare the results.

I see the last elements (bottom right within group) of a previously
grouped and duplicated array of text boxes rendered close to the
original whereas the first elements (upper left within group) appear
pixelated and not anti-aliased.

@skam - I tried to create a simpler clipped text example - can you help
me out with this: I could not figure out from your sample svg file, what
effect you achieve with clipping a text with an unfilled, stroked
rectangle as clipping path. The only (side-)effect I get is that the
clipped text isn't exported as text when saving as PDF (instead it's
rendered as bitmap or converted to path?). What do I miss here? Your
file exports correctly to PDF when keeping text as text (without clipping).

Hi,

I've tested your file (thanks for the work !), and it give the same result than the one you described, with Evince (2.26.1), Adobe Reader (8), or Xpdf (3.02)...
Export as text give good results, but the question is : is the font embeded or not ? I don't think so...
Export text as path give this bad pixelated output (PDF joined), and heavy weight file (relatively).

@~suv : I have clipped a group (which contain the text) into an orange rectangle... because I wanted the white circle to not appear outside this rectangle. Clipping the text was a consequence, not really intended.

PS : it seem that I can't attch the PDF output here... too heavy (almost 5Mo) ?

>Clipping the text was a consequence, not really intended.

I think the clipping/clipped text is a separate issue (exporting clips &
masks), I'll try to find related bugs... At least for your current case
there's a work around ;-)

> PS : it seem that I can't attch the PDF output here... too heavy
> (almost 5Mo) ?

I didn't even try - but trusted Inkscape that the export would be the
same on other systems.

As expected export to '.ps' or '.eps' shows the same bug with text
converted to paths, verified with Preview.app (converts PS, EPS to PDF
on the fly) and with ImageMagick 'display' on OS X 10.5.7.

'Save as pdf, ps, eps' seem to be handled by the internal extension
system (cairo-ps-out.cpp, cairo-renderer-pdf-out.cpp). Anyone with
insight into the code following this bug report?

@skam: A better work around for printing: keep the text clipped as is,
but convert it to paths before exporting to PDF (Select all text objects
with 'Find… > ID:' "text"). This keeps the font face without embedding
the font, and does _not_ trigger the 'texts as paths export pixelated'
bug. Just don't save the SVG file... ;)

related to / maybe duplicate of bug #284680

    confirmed on Windows XP, build 21627. Attached is a .ps file with two O's, the second one produced by a tiled clone, and then using text-to-path. The two O's are significantly different in appearance, and the second one is about 5 times larger than the first, in bytes. Both are represented as paths in the .ps file, but the paths are not "equivalent" or "cloned".
    however, I don't think this is related to Bug 284680, because that bug referred to a complete absence of output, not poor quality output.

    this is a somewhat clumsy workaround but I believe it works : for the text in question, select the master text, choose the menu item Path -> Object to Path. Then export, and you don't need to specify 'Convert Text to Paths', because it has already been done. The resulting .ps file is smaller and appears to be consistent in quality.

thanks for confirming!

On 28/6/09 20:34, Alvin Penner wrote:
> however, I don't think this is related to Bug 284680, because that
> bug referred to a complete absence of output, not poor quality
> output.

What I meant: the patch for bug #284680 revealed this new problem with
pdf/ps/eps export, in other words there may be a relation between the
fix of bug #284680 and the visibility of the poor quality of pdf/ps
output. Maybe hoping that theAdib has recent insight into the relevant
code parts (src/extension/internal/cairo-*)...?

Alvins Postscript file 'O_two.ps' opened with Inkscape reveals that there are 3 paths stacked in place with differing counts of nodes:

line 1: 'O' is drawn by 3 (!) stacked paths
line 2: 'O' is drawn by the lower part of the third path, once - hence it is not rendered as 'pixelated' as the upper one.

@Alvin: how many paths are in the original svg file?

(~suv figured out how to open Postscript files with Inkscape on osx, finally)

doing the same with the first test case from ezrakatz (opening PDF with Inkscape, ungroup)

test.46.pdf: group of 330 objects, when ungrouped, each character is a separate path, no stacked paths
test.47.pdf: group of 10 objects, when ungrouped, 10 large objects, one for each new line, all include the paths of the prevously converted lines + the new one (better illustrated with attached file, open with inkscape - paths are outside the page, firefox doesn't render it)

yes, there is some duplication of paths on top of each other. I've lost the original .svg file but tried to reproduce it here. When I ask for two tiled clones, the first clone lies directly on top of the original O. So I now manually deleted that duplicate and then regenerated the .ps file. The two O's still appear to be different.

re-importing O_clone.ps shows a group of 2 paths, upper 'O' is rendered
twice.

attaching another example trying to illustrate what happens. Somewhere
while parsing the svg-tree for text objects or in a loop (calling the
cairo_glyph_path() function in 'cairo-render-context.cpp'?) a counter
seems not getting reset or updated properly, thus the current text/path
object is appended instead of replacing with every loop.

I will see what I can do. Adib.

Hi all,

I am also suffering from this bug. Before I found this report in the bug tracker, I experimented a bit myself and like to contribute my findings. I use Inkscape 0.47 pre3 on OSX snow leopard.

In attachment you find some files illustrating the problem:

pdfexport_textoutlinebug.svg is the original file: seven text objects (same text: "Désiré oleolee at 33") in just plain old arial, some in black, some in white and two black rectangles.

pdfexport_textoutlinebug_pdfexport.pdf is he result of saving it as pdf with the option "convert text to paths" enabled. As you can see, the color of various text objects is wrong and there are aliasing problems at the edges of the text (see below).

pdfexport_textoutlinebug_import_of_exportedpdf.svg is the result of importing the generated PDF. If you examine this file, you'll see that there is a multiple of the original seven text lines, all overlapping each other (causing the aliasing problems). Also note that there is also a lot of partial lines ("D", "Dé", "Dés", "Dési", ...)

pdfexport_textoutlinebugpdfexport_textoutlinebug_import_of_exportedpdf_exploded.png: manual "unoverlapping" of all the exported text objects in the PDF export on a red background.

I just checked with Inkscape 0.47pre4 r22446, built Oct 16 2009 on Mac OSX Snow Leopard and this bug doesn't appear to be resolved.

I tried 0.47 Pre 4 win 32

Aliasing problems at the edges of text converted to shapes (by pdf export) are caused by overlaid shapes.

The problem only occurs with filled text without outline. No problem for me with only outline text or text with fill and outline.

For example if you type the letters A,B,C,D,E as five separated text objects you obtain five layered objects. The first one below contains only "A", the second "A" and "B", the third "A", "B" and "C", the fourth "A", "B", "C" and "D" and the fifth "A", "B", "C", "D" and "E".

ivan

I can largely confirm the findings of Ivan in #30:
Only-fill text results in wrongly overlaid shapes, text with outlines are exported as desired.

However, if you mix text objects with fill and outlines, things aren't that simple.
E.g. If you have separate text objects "A", "B", "C" and "D", with "A" and "B" fill only and "C" and "D" with outlines,
export to PDF, import again and ungroup,
then you get filled objects:
"A",
"AB",
"ABC"
"D"
(and outline objects "ABC" and "D")

In attachment screenshot of
left) orignal text objects
right) disassembling of the resulting PDF-export

(for completeness: I'm using Inkscapge 0.47pre3 on OS X snow leopard)

Converting stroked text to paths on export doesn't trigger this bug. Setting the stroke-width of the text objects to '0.000' creates PDFs comparable to the quality of PDFs exported with 0.46 (the stroke paths are not included in the PDFs).

Note: even when exporting 'text as text' the stroked outline of text objects is converted to a path whereas the (filled) text objects are still text objects when re-opening the PDF with Inkscape.

Adding all stroke properties (with 'stroke-width:0') to the text style-attribute creates correct PDF output (although in Apple's 'Preview' PDF viewer the 'text-as-text' is rendered slightly bolder than the 'text-to-path' variant). Tested with examples added in comment #4 and #28.

Is it possible that this bug is connected to (or triggered by) the changes described in the release notes under 'Optimized CSS properties'?
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#SVG_support>:
«As a file size optimization, Inkscape does not write into SVG some of the stroke properties if the object has stroke:none»

This patch fixes the issue for me. It looks like the path is not cleared when cairo_restore is called in extension/internal/cairo-render-context.cpp, function renderGlyphtext. Please test.

I can confirm the fix for another file.
It uses Georgia and Karabine; you can get Georgia from ttf-mscorefonts-installer and Karabine from here:
http://www.dafont.com/karabine.font

pre4 gives 6 MB, multiple overlapping paths
SVN after my patch gives 920 KB, single paths (correct)

Patch tested and fix confirmed with Inkscape 0.46+devel r22557+patch on OS X 10.5.8, Cairo 1.8.8

test: export to PDF (Convert texts to paths) of attached SVG examples from
comment #4: <http://launchpadlibrarian.net/28012678/test.47.svg> (result attached)
comment #7: <http://launchpadlibrarian.net/28285829/planche-carte-visite-coodysse2.svg>
comment #28: <http://launchpadlibrarian.net/33564210/pdfexport_textoutlinebug.zip>

Also tested and fix confirmed with
comment #35: <http://launchpadlibrarian.net/35279288/plakat.svg>

There seems to be a small difference between the document structure of
a) export with option 'Convert text to paths'
b) menu 'Path > Object to Path' and then export
noticeable in the time the PDF viewer (here: Apple Preview.app) takes to render the PDF (somewhat slower for the 'export as t2p' than the 'o2p then export' variant) and in the total number of groups when opening the PDFs in Inkscape. I do not know if this has any relevance (as long as there are no apparent rendering or filesize differences).

<off-topic>launchpad - please implement comment edit function ;-)</off-topic>

the difference: the menu command 'Object to Path' in 0.47 converts the characters to grouped individual paths whereas the export option 'Convert texts to paths' works as in 0.46 by converting text objects to combined paths.

This is documented behavior of Object to Path that was added in 0.47.
http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Converting_text_to_path_produces_a_group

Thanks for your work Mr Kosinski, I'll test it as soon as possible (on Monday I think)

Thanks, patch tested and committed (without the style.cpp part which is unnecessary) in rev 22562.

@Krzysztof: I have discovered a small glitch that was introduced by your patch: when exporting stroked text with different color for stroke and fill to PDF, the fill color is set equal to the stroke color (both when exporting text as text or texts as paths.

To verify it I tested and reverted each of the last 6 commits down from 22566:

r22562 has that error
r22561 keeps separate colors for fill and stroke
r22561 + your original patch has the error

sorry that I missed that before... Could you try if you can reproduce this with the attached file?

I put the style setting in wrong places. Here is a fix.

Quick test looks good here: both fill and stroke color are correct in exported PDF. Thanks!

thanks, committed in 22567

Tested with svn22575 on Ubuntu 9.10 64bits with all test files here and some works of mine, I confirm the fix is well done !
Thanks again for your work

Altough I see that is has been an issue back in 2009, I do still observe this behavior in Inkscape 0.48.3.1 r9886 under Ubuntu Linux 12.04.
Exporting to PDF with set property "Convert text to paths" renders fonts with an additional outline. Is this a regression from 0.47 to 0.48?

@KoenigGunther - to the best of my knowledge this report has been fixed and did not return in later stable versions.

Possibly your SVG file has stroked faux-italic (or faux-bold) styled text, and in the exported PDF file the stroke outline and the filled text use different styles, similar to
- Bug #586028 “Italic text doesn't work with pdf export”
Underlying issue is tracked in:
- Bug #200899 in Inkscape: “Font style ignored in eps/pdf output”

If none of these match you issue, please file a new report, and attach sample SVG and PDF files to allow further investigation.