[gs-bugs] [Bug 691471] PDF 1.7 FTS: /unregistered in --run--

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Tue Jul 20 07:54:59 UTC 2010


--- Comment #10 from Ken Sharp <ken.sharp at artifex.com> 2010-07-20 07:54:55 UTC ---
(In reply to comment #9)
> OK.  I have made a bit of progress on this but I am looking for some
> suggestions.

Remember, you asked for it :-)

> Clearly there needs to be some pdf14 device method
> that is invoked here, so that a new group is pushed and the result is composed
> with what ever is already drawn and the trans entry of the tile is used during
> the tiling process.

Shouldn't the compositor image method be executed ? 

>  Not being familiar with the font rendering I am looking
> for a bit of advice here on how the pdf14 device intercepts in the above set of
> operations or if we could do a path fill for the glyph.

Well, there isn't really a device method for pdf14 to intercept, other than the
image method, because we are at a lower level than that. We've already created
a bitmap of the glyph from the glyph program, and we use that as a mask to draw

I *think* the way this usually works for patterns is that the pattern tile has
already been rendered (tbits) and we just use the glyph bitmap as a mask for
the pattern tile, tiling as required if the glyph lies across a tile boundary.

In order to make a path fill we would have to realise during the show that we
are filling with a pattern. We would also want to recognise somehow that the
pattern involves transparency. We do already have a test for that in the
pattern loading code. On return from the Pattern PaintProc, passing through
show for the second time, we would need to execute a charpath/fill instead of a
simple show.

I'm sure that's possible but it just feels like the wrong approach, also I'm
not sure how this would translate into high level output. I strongly suspect
that the text would be converted to a path. This has multiple problems; it
would be impossible to edit the text in Acrobat afterwards. If the font is not
embedded then the result might be permanently incorrect (we would convert to
charpath with the wrong font) and finally, the file would be potentially
considerably larger.

Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the gs-bugs mailing list