Upside-down text with PDF

[Twusk]

When saving an Inkscape document that includes text boxes as PDF via Cairo with "Convert text to paths" unchecked, text is flipped vertically in the resulting PDF.

Tested this using 0.46-pre1 on Windows XP SP2 and Windows Vista Business.

Might have a similar explanation as bug #169126? I want to make sure it is noted that this occurs on export as well.

I will attach my files in a second if I can figure out how to do that. To reproduce this, all I did was open a new Inkscape document and draw a few random text boxes with random text and save as PDF via Cairo.

[Ryan Lerch (ryanlerch)]

i can confirm that this occurs on windows vista business...

On Feb 6, 2008 9:39 AM, Twusk <email address hidden> wrote:

>
> ** Attachment added: "drawing.pdf"
> http://launchpadlibrarian.net/11783441/drawing.pdf
>
> --
> Upside-down text with PDF Export
> https://bugs.launchpad.net/bugs/189432
> You received this bug notification because you are a member of Inkscape
> Bug Team, which is the bug contact for Inkscape.
>

[Tom Davidson (tjd-mit)]

Hmm... can't confirm under linux with yesterday's SVN (rev 17236) using your test file. Attaching the pdf I get as output. Do you know what version of cairo you have? Can someone else with Windows test this?

Here are my versions of everything cairo-related:

$ rpm -qa|grep -i cairo

pycairo-1.2.6-1.fc6
cairo-java-1.0.5-3.fc6
cairo-devel-1.2.6-1.fc6
cairomm-1.2.4-1.fc6
cairomm-devel-1.2.4-1.fc6
pycairo-devel-1.2.6-1.fc6
cairo-1.2.6-1.fc6

[Rygle (rygle)]

If you open the original PDF supplied by Twusk and hit Ctrl-D, it says "PDF Producer: Cairo 1.5.6" - which is what comes with the win32 dev builds since 0.46-pre1 came out on January 31.

When you do the same on your linux produced version, it says it's a much earlier version - "PDF Producer: Cairo 1.2.6". It is also about 10K larger for exactly the same content. Tom - Have you tried the latest Cairo builds on your system?

I noticed that there's the suggestion on the cairo forums of using a function to narrow down whether a bug is Cairo or Inkscape related.

From http://lists.cairographics.org/archives/cairo/2008-January/012797.html

> Oh, and another thing that might be very useful here is if you could
> run the buggy rendering with inkscape with libcairowrap, (google for
> details and ask here if you get stuck). That will give us a nice view
> into exactly what cairo calls inkscape is making and will allow us to
> eliminate the possibility of bugs in inkscape rather than cairo.

I am not tech enough to do this sort of stuff, but this may help someone else a bit more so.

[Tom Davidson (tjd-mit)]

Rygle--thanks for all the extra info! It looks like it will be very helpful, and may also explain why this is turning up mainly on Windows... 1.2.6 is the latest version of Cairo shipped for my OS (Fedora Core 6), so it's not easy for me to test newer builds. But maybe someone with a more recent distro can take a look at this...

[Tom Davidson (tjd-mit)]

Suggesting 0.46 milestone since this is an important recent regression in a key new feature

[Bryce Harrington (bryce)]

If it turns out to be particular only to newer Cairo releases, we can probably re-milestone this to 0.46.1

[Tom Davidson (tjd-mit)]

If Inkscape packages the newer cairo releases with Windows, doesn't
that make it our problem? perhaps we can choose to ship an older
version of Cairo?

[Bryce Harrington (bryce)]

Right, the issue becomes just a packaging issue for the windows packagers to sort out, so it doesn't need to be solved for 0.46.

As well, in order for this bug to remain milestoned at all, we need an assignee for it. We can't block a release on a bug with no one to own it.

[Wolfgang Stöggl (c72578)]

The current stable release of cairo is 1.4.14 whereas the 1.5.6 version is a so called snapshot. Testing and packaging of the stable version would probably make sense.

[Tom Davidson (tjd-mit)]

Wolfgang--thanks for this piece of information. I will try to pass it along to the Windows packagers...

[Tom Davidson (tjd-mit)]

I have since updated my linux system to Cairo 1.5.8, and I don't have this problem. So it doesn't seem to be 1.5-specific.

It could still be due to an interaction between 1.5 and Windows (i.e. rolling back Cairo might help), but it's not *solely* due to the use of bleeding-edge cairo...

[Adrian Johnson (ajohnson-redneon)]

I don't believe this is a cairo problem as Mozilla are using cairo and can export to pdf on Win32 without any problems.

The attached pdf in comment 2 has the font matrix set to an upside down matrix ie the yy is negative.

Adding some printf statements to extension/internal/pdf-cairo.cpp and testing under Linux I see that:

- RENDER_WITH_PANGO_CAIRO is not defined. I would have expected that with cairo pdf enabled, this should be enabled.

- The cairo ctm is upside down (xx = 0.8, yy = -0.8) while exporting drawing.svg. I could not see where this inverted ctm was coming from however using an inverted ctm requires an inverted font matrix to get text the right way up.

- With RENDER_WITH_PANGO_CAIRO not defined, the font matrix was being inverted (PrintCairoPDF::text, line 883) :
     matrix.yy = matrix.xx;

This resulted in the text the right way up in the exported PDF.

If I add

#define RENDER_WITH_PANGO_CAIRO 1

to the top of the file, the #ifdef'ed code does not invert the font matrix and the exported text is upside down.

I don't have the time to try building Inkscape under Windows however I am guessing that RENDER_WITH_PANGO_CAIRO is defined when building on Windows and would would explain why the text is upside down on Windows but not Linux.

[theAdib (theadib)]

I committed a patch to the trunk that at least works on linux.
SVN revision 17589.

once reported ok we can put that to the release branch. So I need some feedback.

pls. test :-) Adib.

[Bryce Harrington (bryce)]

Has anyone had a chance to test it?

Patch is attached.

[theAdib (theadib)]

The patch is in the trunk for about one week. Because nobody complains I woud push this to the 0.46 branch. Any comments?

Bryce, what you think?

Adib.

[Alvin Penner (apenner)]

running the win32 binary build from today : Inkscape-0.45+0.46pre3-1.win32.exe
text is still upside down on a Cairo PDF output
PDF file says PDF Producer = Cairo 1.5.12

DOS reports the following messages (the first 2 numbers look like (x,y) coords :

C:\Program Files\Inkscape\python>python inkcl.py
595.275574 841.889771

** (inkscape.exe:3564): WARNING **: Parameter <blurToBitmap> might not exists

** (inkscape.exe:3564): WARNING **: Parameter <blurToBitmap> might not exists

(inkscape.exe:3564): Gtk-CRITICAL **: gtk_widget_grab_default: assertion `GTK_WIDGET_CAN_DEFAULT (widget)' failed

[Alvin Penner (apenner)]

attaching the file

[Alvin Penner (apenner)]

running the more recent win32 build 0803061655.7z, the bug is fixed.
Text is right-side-up and the DOS exit message does not have the x,y coords :

C:\Python25\APP>python inkcl.py

** (inkscape.exe:2824): WARNING **: Parameter <blurToBitmap> might not exists

** (inkscape.exe:2824): WARNING **: Parameter <blurToBitmap> might not exists

(inkscape.exe:2824): Gtk-CRITICAL **: gtk_widget_grab_default: assertion `GTK_WIDGET_CAN_DEFAULT (widget)' failed

[theAdib (theadib)]

You are right the patch does not made into the 0.46 branch and so only works on the latest snapshots. Adib.

[Johan Engelen (johanengelen)]

Just tested the patch on win32 on the release branch (0.46). It works great thanks!

Please apply the patch.

[Bryce Harrington (bryce)]

Thanks, applied to the release branch.

(In the future, it would be helpful to have a patch that contained only the fix. This one included a lot of whitespace fixes, which generally can be ignored for the release branch, but I included them anyway this time.)

[wader (mattias-wadman)]

mattias@florian:~$ dpkg -l|grep inkscape
ii inkscape 0.46-0ubuntu1 vector-based drawing program

I ran into something similar when importing PDF files generated with graphviz

test_unknown.pdf is generated with:
cat test.dot | dot -Grankdir=LR -Tpdf -o test.pdf

test_serif.pdf is generated with:
cat test.dot | dot -Grankdir=LR -Efontname=Serif -Nfontname=Serif -Tpdf -o test2.pdf

When importing test_unknown.pdf the text is up-side-down and flipped left-to-right, the figure looks ok in the preview window.

test_serif.pdf can be imported without problem