Hi all,
I talked with Carl a bit more today about the PDF functionality with Cairo and what it'd take to use it with Inkscape. Here's some additional info. Carl, correct me if I've captured any of this wrong.
Some clarification on libsvg, when Carl said he wasn't supporting it, I interpreted this to mean it needed another maintainer. He clarified this; the reasons he had forked libsvg from librsvg originally was to try out replacing its libart backend with a cairo backend. Now that librsvg uses cairo as it's back end, there's no reason for libsvg to be used, and in fact it lacks capabilities that are in librsvg.
So... The plan going forward would be this. svg2pdf as it exists now is probably ok for a start; it's at least better than we got now, and fits within our existing system. I think it's mainly going to be a packaging issue to hook it into our extension framework.
Beyond that, svg2png needs to be modified to use librsvg instead of libsvg. This is probably a fairly simple task, as svg2png is a really short bit of code.
I told Carl about UberConverter. He wasn't sure if the design of Cairo's PDF functionality would match UberConverter's structure, so a crs2pdf via Cairo may not be the right approach.
Carl also mentioned something called Poppler(?) which does PDF _import_, that works in conjunction with Cairo, and that would give us a good round-trip to and from PDF. This sounds worth checking out.
Bryce
On 12/2/05, Bryce Harrington <bryce@...983...> wrote:
Hi all,
I talked with Carl a bit more today about the PDF functionality with Cairo and what it'd take to use it with Inkscape. Here's some additional info. Carl, correct me if I've captured any of this wrong.
Some clarification on libsvg, when Carl said he wasn't supporting it, I interpreted this to mean it needed another maintainer. He clarified this; the reasons he had forked libsvg from librsvg originally was to try out replacing its libart backend with a cairo backend. Now that librsvg uses cairo as it's back end, there's no reason for libsvg to be used, and in fact it lacks capabilities that are in librsvg.
So... The plan going forward would be this. svg2pdf as it exists now is probably ok for a start; it's at least better than we got now, and fits within our existing system. I think it's mainly going to be a packaging issue to hook it into our extension framework.
Beyond that, svg2png needs to be modified to use librsvg instead of libsvg. This is probably a fairly simple task, as svg2png is a really short bit of code.
I told Carl about UberConverter. He wasn't sure if the design of Cairo's PDF functionality would match UberConverter's structure, so a crs2pdf via Cairo may not be the right approach.
Carl also mentioned something called Poppler(?) which does PDF _import_, that works in conjunction with Cairo, and that would give us a good round-trip to and from PDF. This sounds worth checking out.
Bryce
Poppler is the freedesktop engine for rendering PDFs. It is a friendly fork of XPDF with some hacks from KPDF. Evince uses it. The end goal is that anybody can write a frontend and not have to work about the backend. It may also do other things that I am not aware of.
Corey
On Fri, 2 Dec 2005 15:13:09 -0800, Corey Burger wrote:
Poppler is the freedesktop engine for rendering PDFs. It is a friendly fork of XPDF with some hacks from KPDF. Evince uses it. The end goal is that anybody can write a frontend and not have to work about the backend. It may also do other things that I am not aware of.
The point is that poppler provides PDF parsing in a nice library. It's got multiple backends for rendering already, (cairo, splash, etc.), so hooking up a new backend to "render" to inkscape's internal data structure shouldn't be too much work.
-Carl
On Fri, 2 Dec 2005, Corey Burger wrote:
Poppler is the freedesktop engine for rendering PDFs. It is a friendly fork of XPDF with some hacks from KPDF. Evince uses it. The end goal is that anybody can write a frontend and not have to work about the backend. It may also do other things that I am not aware of.
It is also a Futurama reference. Popplers were a tasty snack, which the also happened to be the young of the Aliens from Omicron Persi 8 who kept invading Earth.
- Alan
On 12/3/05, Bryce Harrington <bryce@...983...> wrote:
Carl also mentioned something called Poppler(?) which does PDF _import_, that works in conjunction with Cairo, and that would give us a good round-trip to and from PDF. This sounds worth checking out.
http://poppler.freedesktop.org/
It's used by Evince
Alexandre
On Fri, 2005-12-02 at 15:06 -0800, Bryce Harrington wrote:
Carl also mentioned something called Poppler(?) which does PDF _import_, that works in conjunction with Cairo, and that would give us a good round-trip to and from PDF. This sounds worth checking out.
I thought I read somewhere that there was an SVG backend to Cairo... that'd probably work the best :)
Also, since there is a SVG backend to GNOME-Print, and Evince uses gnome-print, we should be able to work out something with them to get decent PDF import. I think the biggest difficultly will be handing multiple pages... we need to figure out how we want to handle that in Inkscape in general.
--Ted
I think this is a good idea and worth at least trying as a first step of a Cairo based Inkscape, assuming the Cairo PDF or Gnome-Print extensions now work okay. In my own experience, Cairo libsvg rendering works okay in c++ but it is not very fast compared to the current Inkscape canvas and maybe not as rendering complete as lib"r"svg (but I'm using an older version of Cairo). I believe the next version of Cairo is due out around 12/15 ? A totally Cairo based Inkscape would be nice but might depend on: a) development of a Cairo based drawing canvas b) the transition of the SVG surface from libsvg to librsvg c) speed increases in Cairo.
ps: I've knocked off some of the individual addresses on the mail, since I think they're on the list anyway.
Ted Gould wrote:
On Fri, 2005-12-02 at 15:06 -0800, Bryce Harrington wrote:
Carl also mentioned something called Poppler(?) which does PDF _import_, that works in conjunction with Cairo, and that would give us a good round-trip to and from PDF. This sounds worth checking out.
I thought I read somewhere that there was an SVG backend to Cairo... that'd probably work the best :)
Also, since there is a SVG backend to GNOME-Print, and Evince uses gnome-print, we should be able to work out something with them to get decent PDF import. I think the biggest difficultly will be handing multiple pages... we need to figure out how we want to handle that in Inkscape in general.
--Ted
Ted Gould wrote:
we need to figure out how we want to handle multiple pages in Inkscape in general.
Put them into different layers?
Aaron Digulla wrote:
Ted Gould wrote:
we need to figure out how we want to handle multiple pages in Inkscape in general.
Put them into different layers?
I'd agree... I'm inclined to say that they should be parents of layers. So that each page starts with a layer 1. In the end it's not too terribly far off from how we currently handle layers (since they're really just groups).
-Josh
we need to figure out how we want to handle multiple pages in Inkscape in general.
Put them into different layers?
When PDFs are multiple pages, I think it would be an unusual case for each page to be a layer.
I'd rather import each to a different document, or at least have the option to do so.
-- Michael Moore ------------------------------- www.stuporglue.com -- Articles, software and computer tutorials. www.stuporglue.org -- Donate your used computer to a student that needs it.
Michael Moore wrote:
we need to figure out how we want to handle multiple pages in Inkscape in general.
Put them into different layers?
When PDFs are multiple pages, I think it would be an unusual case for each page to be a layer.
I'd rather import each to a different document, or at least have the option to do so.
Unfortunately we don't have the freedom that Adobe did when making the PDF format. We have to work within the SVG spec, which as far as I know, does not have the ability to store multiple pages in one document (perhaps using viewboxes could accomplish this). For example, we currently achieve "Layers" with the clever use of groups, but it's transparent to the user. I do agree that the option to import to more than one document would be handy though.
-Josh
2005-12-05, h keltezéssel 13.45-kor Joshua A. Andler ezt írta:
Unfortunately we don't have the freedom that Adobe did when making the PDF format. We have to work within the SVG spec, which as far as I know, does not have the ability to store multiple pages in one document
And what about SVG animation? Each page would be one frame. The only difference would be between this and real animations, that there is not time between frames.
As the animation gui is in the planning phase, it can be extend (in my opinion) to handle the multiple page problem too. Maybe with a different UI, but the codebase would be similar.
Thoughts?
--- "Joshua A. Andler" <joshua@...233...> wrote:
Michael Moore wrote:
we need to figure out how we want to handle multiple pages in Inkscape in general.
Put them into different layers?
When PDFs are multiple pages, I think it would be an unusual case
for
each page to be a layer.
I'd rather import each to a different document, or at least have
the
option to do so.
Unfortunately we don't have the freedom that Adobe did when making the PDF format. We have to work within the SVG spec, which as far as I know, does not have the ability to store multiple pages in one document (perhaps using viewboxes could accomplish this). For example, we currently achieve "Layers" with the clever use of groups, but it's transparent to the user. I do agree that the option to import to more
than one document would be handy though.
-Josh
Actually we just need to get round to handling the pageset tag
http://www.w3.org/TR/2004/WD-SVG12-20041027/multipage.html
treating them as a series of root layers with mutually exclusive visibility on the different page trees seems like a sensible way to go, got no idea how to go about doing it tho.
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Joshua A. Andler wrote:
Put them into different layers?
I'd rather import each to a different document, or at least have the option to do so.
Unfortunately we don't have the freedom that Adobe did when making the PDF format. We have to work within the SVG spec, which as far as I know, does not have the ability to store multiple pages in one document (perhaps using viewboxes could accomplish this). For example, we currently achieve "Layers" with the clever use of groups, but it's transparent to the user. I do agree that the option to import to more than one document would be handy though.
How about appending the pages below each other like the "continous view" of acroread?
If there was an autocollapse function or "select all below", it wouldn't be hard to add and remove "pages".
Make each of them a group (probably with a special name) and add some tools to work on such "page" groups (select ranges of them).
Align and spread tools could be used in the usual way to arrange the pages.
On Tue, 6 Dec 2005, Aaron Digulla wrote:
Date: Tue, 06 Dec 2005 21:07:08 +0100 From: Aaron Digulla <digulla@...310...> Reply-To: inkscape-user@lists.sourceforge.net To: inkscape-user@lists.sourceforge.net Subject: Re: [Inkscape-user] Re: [Inkscape-devel] PDF Export/Import via Cairo
Joshua A. Andler wrote:
Put them into different layers?
I'd rather import each to a different document, or at least have the option to do so.
One way or another this would be useful to have. I think the PDF importer in Adobe Illustrator (or was it Photoshop) offered several different options including one like this.
Unfortunately we don't have the freedom that Adobe did when making the PDF format. We have to work within the SVG spec, which as far as I know, does not have the ability to store multiple pages in one document (perhaps using viewboxes could accomplish this). For example, we currently achieve "Layers" with the clever use of groups, but it's transparent to the user. I do agree that the option to import to more than one document would be handy though.
How about appending the pages below each other like the "continous view" of acroread?
I'd be interested and like to see if that would work but I'm not sure it could. For example if you have a shape or curve going off the edge of a page into infinity (not really), but then put another page underneath it your drawing would unintentionally overlap on the other page.
The other possiblity is having each page on a seperate tab like OpenOffice.org Draw, MS Visio and others do.
I expect a lot depends on how the SVG specification expects pages to be done.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
participants (12)
-
Aaron Digulla -
Alan Horkan -
Alexandre Prokoudine -
Bryce Harrington -
Carl Worth -
Corey Burger -
John Cliff -
John Taber -
Joshua A. Andler -
Laszlo -
Michael Moore -
Ted Gould