Hello Miklos,

first thanks for all your work.

It seems that Inkscape does not export the blur to cairo pdf nor cairo-experimental pdf. I filed a bug with a small sample. I did not looked into any code but I think once we have the blur we have to export to pdf as well until the next release.

http://sourceforge.net/tracker/index.php?func=detail&aid=1584935&gro...

HTH,

Adib. ---

Miklós Erdélyi schrieb:

Hi all,

I committed a part of my GSoC work, a Cairo-based simple, naiv SVG renderer which will help to have better quality PDF export. It can be found in extension/internal/cairo-render* and there's a new showGlyphs function in class Layout (Layout-TNG-Output.cpp). Its raster output can be considered usable and might be useful for testing Cairo vs. libnr rendering performance. The new output types in 'Save As' are: 'Cairo PDF experimental' and 'Cairo PNG' (this doesn't have any options yet unlike the PNG export function). Currently the renderer doesn't have any obvious optimization like creating surfaces with only the needed bbox size and not of the full size of the output. It needs Cairo 1.2 since it uses cairo_pop/push_group calls so I have wrapped the code around HAVE_CAIRO_PDF which ensures the correct API version. The SVG element-specific rendering methods are in static methods named like sp_flowtext_render so they could be easily put into the virtual methods of the objects representing these elements in other source files. Please consult the source code for more details (cairo-renderer.cpp). The Cairo-specific rendering part can be found in cairo-render-context.cpp. This renderer supports clipping (objectBoundingBox clipping doesn't work -- does anyone have an idea what could be wrong?), masking, and surface patterns in SVG, among the other straightforward things. I wanted to have more things implemented properly but since September I didn't really have much time to spend on this so I decided to release it in its current state so you can tear it apart :) Unfortunately I haven't finished the Cairo-PDF patches for it yet. I have a working version which is quite unstable with text (isn't shown in layers except for the 'root' layer) and images and which supports masking with constant alpha. I cannot release it because it's such a mess at this point. I know the main problem with this exporter is the fact that first the support needs to be built into Cairo in order to take advantage of this exporter and that won't happen overnight, but at least now Inkscape has a simple Cairo-based SVG rendering backend. I hope to get the Cairo-PDF patches into Cairo 1.4.x. Any ideas, comments regarding the subject are welcome.

Cheers, miklos

---

Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Thu, 2006-10-26 at 12:41 -0400, MenTaLguY wrote:

On Thu, 2006-10-26 at 10:46 +0200, Adib Taraben wrote:

...

It seems that Inkscape does not export the blur to cairo pdf nor cairo-experimental pdf.

Cairo doesn't directly support blur, and as far as I know won't ever.

That doesn't mean we can't do blur with a Cairo-based renderer, of course, but it does mean we'd need to implement it ourselves using an intermediate image surface.

The bigger problem is that there's no way to represent blur in PDF. If you want blur in exported PDFs, you'll have to resort to rasterizing blurred objects at some fixed resolution.

cworth, maybe you could chime in on this and the best way to handle this :)

Jon

On 10/27/06, Carl Worth wrote:

Correct. Cairo does not supply a blur operation.

BTW, according to Save As/Save As Copy dialog there are three PDF exporters in Inkscape now, two of them rely on Cairo and have different sets of features. E.g. the first one saves text and doesn't save clipping path, the second saves clipping path but drops text.

Which one do you keep for 0.45?

Alexandre

On Thu, 2006-10-26 at 16:02 -0700, Carl Worth wrote:

hope this helps. Here's a pointer to the most recent conversation we (MentalGuy and myself) had about this on the cairo list:

http://lists.freedesktop.org/archives/cairo/2006-March/006577.html

There are some API suggestions there, but we've never seen an attempt at an implementation yet.

Is Keith now willing to accept an API which doesn't entail a full software implementation of GLSL up-front? That's basically why I finally gave up.

[ See the (belated) continuation of the thread here:

http://lists.freedesktop.org/archives/cairo/2006-September/007760.html ]

Aside from that though, since we had these discussions, I realized that perhaps we should be looking at is the potential for cairo/GEGL integration. It's possible that cairo doesn't really need a full-fledged effects API, just some hooks to allow better interoperation with stuff like GEGL.

-mental

On Fri, 27 Oct 2006 15:13:53 -0400, MenTaLguY wrote:

Is Keith now willing to accept an API which doesn't entail a full software implementation of GLSL up-front? That's basically why I finally gave up.

[ See the (belated) continuation of the thread here:

http://lists.freedesktop.org/archives/cairo/2006-September/007760.html ]

Ah! Well I happened to agree with you on that thread, and my opinion matters much more than Keith's here. He's certainly not about to veto anything we want to do with cairo.

I read his stuff as "you might end up wanting more than this anyway", which I can agree with. But I don't think we need to start with the full-fledged programmable shaders thing before we can provide something as simple as a blur.

Aside from that though, since we had these discussions, I realized that perhaps we should be looking at is the potential for cairo/GEGL integration. It's possible that cairo doesn't really need a full-fledged effects API, just some hooks to allow better interoperation with stuff like GEGL.

That may be too. But GEGL's going to be all-software, right? (At least for now). I agree we don't need to provide an API in cairo to be able to do totally arbitrary effects, but when something like a convolution filter is _so easy_ for almost any hardware to do, it's a shame that cairo isn't exporting any easy way to get at that.

-Carl

On Fri, Oct 27, 2006 at 03:18:02PM -0400, MenTaLguY wrote:

On Fri, 2006-10-27 at 14:59 -0400, MenTaLguY wrote:

...

Ah... can we merge them? Seriously. I don't think the users will like that state of affairs very much...

In fact, frankly I think we should block the release until we've got a single PDF exporter with all the functionality rolled in.

If we do this (and I agree it makes sense), then we must have a plan on how to do it, and someone to be point person on the effort for making the decisions. If someone can identify these two things, then we can make this a hard block on the release.

Bryce

On Fri, 2006-10-27 at 12:58 -0700, Carl Worth wrote:

That may be too. But GEGL's going to be all-software, right? (At least for now). I agree we don't need to provide an API in cairo to be able to do totally arbitrary effects, but when something like a convolution filter is _so easy_ for almost any hardware to do, it's a shame that cairo isn't exporting any easy way to get at that.

Yeah... unfortunately for Inkscape, we still need to implement the rest of the SVG raster effects as well. If I understand correctly, GEGL already provides them, so I'd tend to choose it over re-implementing them manually. At that point we may as well use GEGL for blur too, rather than attempting some kind of messy mixed-mode arrangement.

But, the other part of it is that the GEGL API does seem amenable to acceleration if someone wanted to do it now, and the architecture of a cairo-based filter API is likely going to have to be similar in design. Is this a wheel we need to reinvent in cairo?

-mental

On Fri, 27 Oct 2006 17:51:56 -0400, MenTaLguY wrote:

But, the other part of it is that the GEGL API does seem amenable to acceleration if someone wanted to do it now, and the architecture of a cairo-based filter API is likely going to have to be similar in design.

That all sounds fairly reasonable.

Is this a wheel we need to reinvent in cairo?

We don't need to, of course. I'll just leave it to whoever does the work to decide the best place to do it, (which is how it always works anyway).

-Carl

On Sat, Oct 28, 2006 at 03:26:35PM -0400, MenTaLguY wrote:

On Fri, 2006-10-27 at 13:16 -0700, Bryce Harrington wrote:

...

If we do this (and I agree it makes sense), then we must have a plan on how to do it, and someone to be point person on the effort for making the decisions. If someone can identify these two things, then we can make this a hard block on the release.

Well, since Alexandre hasn't expressed interest in heading this up, I guess I'll do it. It's a pretty bad situation to begin with, but after all those Slashdot posts, it's also a question of personal honor for me.

So, first step. Compile that feature matrix. I'll prep a spreadsheet.

Cool, sounds good. We'll pause the release to allow for time to be focused on this. I bet combining the various efforts into one will produce a very killer feature. :-)

Bryce

On Sat, 2006-10-28 at 13:18 -0700, Bryce Harrington wrote:

• Identify feature differences between the three PDF implementations

Here's what I've got so far, though looking at the issue list for the cairo stuff, it looks like I could stand to add some additional features to the spreadsheet.

Feature Extension "PDF" (pdf-out.cpp) "Cairo PDF" (cairo-pdf-out.cpp) "Cairo PDF experimental" (cairo-renderer-pdf-out.cpp) stroke-opacity (solid) yes yes yes fill-opacity (solid) yes yes yes linearGradient (fill) yes incorrect incorrect linearGradient (stroke) no incorrect incorrect radialGradient (fill) yes incorrect incorrect radialGradient (stroke) no incorrect incorrect stop-opacity no yes yes image yes yes yes fill-opacity (gradient) no yes yes stroke-opacity (gradient) no yes yes text (as text) no no no text (as path) yes yes yes flowText (as text) no no no flowText (as path) yes yes yes opacity (path) yes yes yes opacity (image) no yes yes opacity (fill +stroke) incorrect incorrect incorrect opacity (group) incorrect incorrect incorrect

It looks like today, with stock Cairo 1.2 in Ubuntu, the general results are better with the Cairo PDF backends than the "legacy" PDF backend.

However, given the features I tested above, we've got three problems:

1. Gradient rendering problems resulting from the use of CAIRO_EXTEND_NONE instead of CAIRO_EXTEND_PAD (although we'll also need to see whether CAIRO_EXTEND_PAD is supposed by the stuck PDF backend...).

2. There's no option to embed text as text.

3. _ALL_ the PDF implementations seem to have been written with the bogus idea that alpha compositing is commutative/distributive. Compositing two rectangles with 0.5 alpha is NOT the same thing as compositing a group (of two rectangles) having 0.5 alpha. Similarly with fills and strokes, which should be treated as if there were a group containing a fill object and a stroke object, rather than simply multiplying fill-opacity and stroke-opacity by the object opacity.

• Cairo-based PDF renderer
  • Add optimizations like creating surfaces with only the needed bbox size, rather than the full size of the output
  • objectBoundingBox clipping doesn't work... need to find out why
  • Cairo-PDF patches are not yet finished. These will need to be incorporated into Cairo.
  • Text is quite unstable (isn't being shown except in 'root' layer)
  • Images are unstable
  • Masking is supported only with constant alpha

Can Miklós or somebody separate these into the issues that need to be addressed at the Cairo level, and the issues which need to be addressed in our own backend?

• Ensure blur works with export to pdf via rasterizing of blurred objects in a fixed resolution

Unless someone's feeling extra motivated, we'll probably have to punt on PDF blur for this release.

Could someone suggest ways to test everything that'll need to be supported?

doc/PDF Feature Matrix.svg has test cases for everything on the corresponding spreadsheet. I'm afraid that none of the Open Source PDF viewers I've tried so far have complete enough support for PDF to do the entire test suite correctly, so the test results will have to be checked in Adobe Acrobat Reader.

-mental

On 10/27/06, MenTaLguY <mental@...3...> wrote:

On Fri, 2006-10-27 at 12:58 -0700, Carl Worth wrote:

...

That may be too. But GEGL's going to be all-software, right? (At least for now). I agree we don't need to provide an API in cairo to be able to do totally arbitrary effects, but when something like a convolution filter is _so easy_ for almost any hardware to do, it's a shame that cairo isn't exporting any easy way to get at that.

Yeah... unfortunately for Inkscape, we still need to implement the rest of the SVG raster effects as well. If I understand correctly, GEGL already provides them, so I'd tend to choose it over re-implementing them manually. At that point we may as well use GEGL for blur too, rather than attempting some kind of messy mixed-mode arrangement.

GEGL doesn't yet implement all of the SVG raster effects. Some are implemented, some under way and others waiting for someone to code them. I've also considered making the XML parser for GEGL compositions support reading SVG filters (and reuse them in the composition trees already supported by the XML parser.)

But, the other part of it is that the GEGL API does seem amenable to acceleration if someone wanted to do it now, and the architecture of a cairo-based filter API is likely going to have to be similar in design. Is this a wheel we need to reinvent in cairo?

Cairo wouldn't necessarily want to reinvent the entire wheel, but at least provide means to use the commonly desired filters that lend themselves easily for hardware acceleration. To me GEGL as a dependency for cairo seems top-heavy.

Optimization has not been a priority for GEGL yet, And it is designed to be able to cope with larger than RAM images with processing done with 128bit/pixel (32bit floating point/component). Lesser demands that can be optimized are taking a back seat to get a reference implementation with readable code working first.

The reason there is no release of GEGL yet, is that time has not been found to verify exactly what APIs should be exported, and how to present that API. There is working test code now, it exercises and demands expansion of the public API, this will probably help solidify the needed APIs.

Once GEGL itself works well enough, with a stable API. Focus will probably be diverted to adding support for registering optimized paths for different pixel formats (where some of the formats might indicate GPU processing).

/Øyvind K.