[poppler] Image optimization
jeff at infidigm.net
Sun May 22 06:52:57 PDT 2005
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
> >> >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
> >The cairo backend draws by string, whereas the splash backend draws by
> 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
glyphs[i].location = glyph.location;
More information about the poppler