Hi everyone,

I'm trying to generate high-quality, small-size PDF files from SVG on Linux. All of these SVGs were created with Inkscape 0.46 (mostly Win32, with some modifications on Linux). However, they must be converted on the server-side which runs Linux (Centos 5.3 Final 64-bit). It made sense to me to use InkScape from the command-line since it would have the same feature-set and rending quirks that we saw in the UI (and that seems true).

My problem is that when I try to use the -A command-line parameter, it creates PDF files that have been rasterized, rather than trans-coding them into a vector form of PDF. Those files are huge, and they don't scale well. Here is a simple sample SVG and the resulting PDF:
http://drawmea.binko.net/tests/test1.svg
and
http://drawmea.binko.net/tests/test1.pdf

The SVG is 16K and the PDF is almost 200K. (That 10:1 ratio seems to get worse as the complexity of the SVG goes up.)

I spoke to the folks on IRC, and they were able to create a good (19K) vector version of the PDF with their version of 0.46.

I would like to know just what might be causing this. I am fine with re-installing libraries or the like, but I have found building InkScape from scratch on 64-bit to be quite a challenge and don't want to start blindly.

Can anyone point me in the right direction?

Thanks
Bill

Are you sure the people on IRC were using 0.46? Exporting to pdf has been improved in the pre0.47 versions, you can try the latest one and test the file.

I have no problem using 0.47pre, or even a specific development version.

However, building from source on CentOS 64-bit is a bit of a nightmare. The number of libraries that need to be upgraded is nuts, and the configure script has picked 32-bit versions if they are installed...

Does anyone know of a Centos RPM or even a HowTo or Guide to building on that platform? Unfortunately, switching off of CentOS is a difficult proposition at this point, and probably the one thing that I can't do without higher approval.

Thanks

I've done quite a bit more futzing around with this tonight, and here's some more input.

1) Inkscape .46 on Win32 does indeed export the PDF exactly as I'd like
2) Inksscape SVN HEAD is beyond my ability to build on CentOS 5.3. This comes down to CentOS not having new enough glibmm libraries, and the inability (without massive surgery) to upgrade part of Gnome without messing up the rest.

I'm now down to several options, none of which I like:

1) Re-Build the entire server on a different distro. This is tempting as CentOS is a bit of a pain in the butt. I have mostly RedHat-style experience, so I would probably move to Fedora 11 which I have running on other boxes, but might consider another distro if any are "perfect" for this type of server-side conversion. However, it's a massive amount of work, and will impact other teams and probably take the server offline for several days as we bring it in from the colocation site, do the work and redeploy.
2) Use Batik to do the PDF conversion. This works, but with a different set of bugs -- in this case, it looks like "middle anchored text" will not render correctly. See http://drawmea.binko.net/tests/batik1.pdf I don't really want to do this, because we do all of the SVG editing in Inkscape and using a completely different renderer introduces lots of places for things to look imperfect.
3) Start with mod_rsvg and write a simple librsvg->libcairo export for PDF. This doesn't look that hard, and would actually give me some benefits. However, the downside is much like #2 -- I'm using a different render path than Inkscape (which doesn't use librsvg, correct?)
4) Put up with this until CentOS puts out 5.4 or whatever version upgrades Gnome to libraries that let me build .47. This simply has too much risk -- we need this done.

Of course, it's irritating that .46 works on Windows. It makes me think that I COULD get .46 to do this correctly on Linux with the right library versions/configuration. Is everyone sure this isn't something that can be fixed in .46? I'd hate to do any of the options above if they're not needed.

Thanks,
Bill