[poppler] Image optimization
leonardr at pdfsages.com
Sat May 21 22:38:58 PDT 2005
At 11:40 PM 5/21/2005, Jeff Muizelaar wrote:
>I don't quite understand what you mean. Can you draw semi-transparent
>circle with splash?
You do, however, have to specify that you want an alpha channel
when you specify the SplashColorMode:
splashModeARGB8, // 1 byte per component, 4 bytes per pixel:
splashModeBGRA8, // 1 byte per component, 4 bytes per pixel:
I submitted to Derek, and it will be in the next Xpdf release, support
for rendering to a CMYK output buffer:
splashModeCMYK8, // 1 byte per component, 4 bytes per pixel:
splashModeACMYK8 // 1 byte per component, 4 bytes per pixel:
>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.
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.
> > >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...
Pixel by pixel is done since the logic of transformations is
handling in the OutputDev while Splash only worries about the buffer.
>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??
>So doing code sharing is harder without changing splash to draw by string
Or better - changing Cairo to draw char by char.
Leonard Rosenthol <mailto:leonardr at pdfsages.com>
Chief Technical Officer <http://www.pdfsages.com>
PDF Sages, Inc. 215-938-7080 (voice)
More information about the poppler