bulia byak escribió:

This sounds like you have antialiasing turned off. Turn it on in Acrobat prefs and it might help. If at least one application show it properly, this means it's most likely with the PDF viewing applications, not with Inkscape's PDF.

I find this a bit strange, how can gpdf render it correctly, but xpdf (its "parent" app) not render it correctly? I've only used a couple times the PDF exporter in Inkscape (and that was with version 0.43), however I usually converted to paths text elements to avoid any problems (mainly with fonts).

roland donat wrote:

It seems that you are right Bulia. The problem comes from my PDF viewver. I don't now why but it works with acroread today... But with xpdf, the problem persists. I will focus my investigation on the difference between xpdf and its child gpdf!

I don't know the history of the projects, but I would assume that if gpdf is a fork of xpdf, then it was a port to the GTK graphics library, right?

In general, I believe the attraction to toolkits like GTK is that they are more powerful, better rendering libraries, so the problem may be between the drawing routines and the library functions called, rather than in the interpretation of the PDF (i.e. xpdf "knows" what it wants to draw, but can't, because the graphics library is limited?).

But of course, I'm only speculating. I too have noticed problems with xpdf, especially with transparency and overlapping PDF elements, relative to gpdf. Unfortunately, I still have to use xpdf a lot, because it can grab text (I think it's the only free PDF viewer with that feature).

In fact, in light of the Linux Printing organization's desire to embrace PDF as "the new Postscript", I find the state of free PDF viewers to be pretty sad. I actually had to download acroread a few days ago in order to verify the internal structure of PDFs I was generating (things like what fonts were included, etc). Seems like one of the industry stakeholders ought to put some effort behind that, if they really like PDF that much.

Cheers, Terry

Terry Hancock escribió:

roland donat wrote:

...

It seems that you are right Bulia. The problem comes from my PDF viewver. I don't now why but it works with acroread today... But with xpdf, the problem persists. I will focus my investigation on the difference between xpdf and its child gpdf!

I don't know the history of the projects, but I would assume that if gpdf is a fork of xpdf, then it was a port to the GTK graphics library, right?

In general, I believe the attraction to toolkits like GTK is that they are more powerful, better rendering libraries, so the problem may be between the drawing routines and the library functions called, rather than in the interpretation of the PDF (i.e. xpdf "knows" what it wants to draw, but can't, because the graphics library is limited?).

May be, but I've seen a lot of PDFs with drawings on them with xpdf just fine... maybe these drawings were ps/eps prior to their inclusion in the PDF.

But of course, I'm only speculating. I too have noticed problems with xpdf, especially with transparency and overlapping PDF elements, relative to gpdf. Unfortunately, I still have to use xpdf a lot, because it can grab text (I think it's the only free PDF viewer with that feature).

Well, evince (yet another fork from gpdf, or that much I can tell) and Kpdf, both support grabbing text, area (text/images in a selection which will be exported as an image) and images, so long the PDF allows it.

In fact, in light of the Linux Printing organization's desire to embrace PDF as "the new Postscript", I find the state of free PDF viewers to be pretty sad. I actually had to download acroread a few days ago in order to verify the internal structure of PDFs I was generating (things like what fonts were included, etc). Seems like one of the industry stakeholders ought to put some effort behind that, if they really like PDF that much.

Cheers, Terry

I didn't know that Linux printing and other projects are slowly moving in the direction of Mac of making PDF the new "definition" format. Not that it is a bad idea, only that (I believe) PostScript has been around for quite a bit longer than PDF, and to the best of my knowledge, both formats were created by Adobe.

Alan Horkan wrote:

On Thu, 21 Sep 2006, roland donat wrote:

...

Date: Thu, 21 Sep 2006 09:02:05 +0200 From: roland donat <roland.donat@...155...> Reply-To: Inkscape User Community inkscape-user@lists.sourceforge.net To: Inkscape User Community inkscape-user@lists.sourceforge.net Subject: Re: [Inkscape-user] PDF export - dirty overal rendering (text, lines...)

Thanks for your answers.

It seems that you are right Bulia. The problem comes from my PDF viewver. I don't now why but it works with acroread today... But with xpdf, the problem persists. I will focus my investigation on the difference between xpdf and its child gpdf!

If you want the best results use up to date software.

You should upgrade to Evince instead. http://www.gnome.org/projects/evince/

Evince or otherwise, there's no way I've been able to save an Inkscape file that has transparency, text, and pictures and have it read as it should. I have the latest of them all, Evince 0.5.1 using 'poppler' 0.5.1 (cairo), Xpdf v3.01, Kpdf 0.5.4, under FC5.

frank

Benjamin Huot wrote:

...

Evince or otherwise, there's no way I've been able to save an Inkscape file that has transparency, text, and pictures and have it read as it should. I have the latest of them all, Evince 0.5.1 using 'poppler' 0.5.1 (cairo), Xpdf v3.01, Kpdf 0.5.4, under FC5.

Try Ghostscript, Ghostview or Kghostview.

These are the best open source viewers I have found.

KGhostView 0.20 doesn't handle transparencies... don't have Ghostview on the machine... Ghostscript is only for PS, huh?

Thanks anyway.

frank