[poppler] Image optimization

[Jeff Muizelaar]

On Sun, May 22, 2005 at 01:38:58AM -0400, Leonard Rosenthol wrote:
> At 11:40 PM 5/21/2005, Jeff Muizelaar wrote:
> >The eventual goal is to change this xpdf code into a set of support
> >functions that the backends can call if they don't support
> >patterns/shading natively. This will allow us to use cairo's support for
> >shading and patterns.
> 
>         IMO, that's a BAD idea unless you expect Cairo (or Arthur, etc.) 
> to support EXACTLY (and completely) the renderings required by the PDF 
> specification.  There is a LOT of stuff that is quite PDF-centric about the 
> rendering of both of these things - in fact, Derek and I are discussing a 
> discrepancy with pattern rendering between Xpdf and Acrobat based on an 
> ambiguity in the PDF Reference.  This is the type of thing that if you move 
> to a Cairo (etc.) rendering model, you will have problems with.

They don't need to support everything exactly. The current code is not
being ripped out. It is just being moved. If a backend doesn't support a
certain type of the shading properly they just call the helper methods
which decompose it into simpler primitives.

> 
>         Transparency support only compounds this, as Cairo (for example) 
> only offers simple alpha blending - but nothing like the full transparency 
> model of PDF (blending modes, transparency groups, etc.) and trying to mix 
> that with shading and pattern ops is asking for trouble.

Cairo should eventually support the additional blending modes. See
http://lists.freedesktop.org/archives/cairo/2005-May/003873.html

> 
> 
> >> >It also is not very suited to hardware acceleration.
> >>
> >>         Why?
> >
> >The way splash does images is by doing the compositing pixel by pixel
> >instead of blitting a buffer.
> 
>         True, but that has no bearing on hardware acceleration...

Yes it does. No hardware is going to support this type of operation. I
don't think it would be trivial to make Splash do image composting this
way.

> >The cairo backend draws by string, whereas the splash backend draws by
> >character.
> 
>         Has enough testing been doing on a variety of document (esp. CJK 
> with vertical and unusual interchar/interword spacing) to validate this 
> model?  That's why Splash draws char by char, since Xpdf handles the 
> complexities of font metrics vs. PDF metrics when drawing a string.  Does 
> the Cairo backend address this??

I haven't actually tested it with those things because I couldn't find
any pdfs that used them (esp. the vertical writing mode). However, there
shouldn't be any problems. It is basically the difference between

Splash:
foreach(glyph) {
	putGlyph(glyph, glyph.location);
}

and

Cairo:
foreach(glyph) {
	glyphs[i].location = glyph.location;
}
putString(glyphs);

-Jeff