[Poppler-bugs] [Bug 2807] doesn't handle text rendering modes

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sun Aug 1 02:13:32 PDT 2010


https://bugs.freedesktop.org/show_bug.cgi?id=2807

--- Comment #24 from thomasf <Thomas.Freitag at alfa.de> 2010-08-01 02:13:32 PDT ---
(In reply to comment #22)
Forget it, Albert. When I went back to old source, I still used SPLASH_CMYK.
Now I change it to SPLASH_RGB, and the output is like Yours. Reason for this
strange behaviour is a bug in the old source interpreting render mode:
1. The text should be rendered in pattern colorspace.
2. After begin text, there is a "0 Tr", which changes rendering mode from 7
(caused by pattern colorspace) back to 0.
3. Now drawing characters is done again with splash->fillChar instead of
setting a clipping path, and this uses color 0, therefore in SPLASH_CMYK it
become white, but in SPLAH_RGB black, but with text antialising, which looks
much better.

The actual patch now correct this, so drawing characters still is done by
setting clipping pathes and later fill it with the pattern colorspace, but
unfortunately here we have, as I already mentioned, no antialising, so the
output looks worser, even if the behaviour now is correct. 

You would have seen that, if the pattern colorspace uses for example red as
base color, without the patch the text still would be paint black, with the
patch it would be paint red, but looses the antialising.

So what I have to do (I'm not sure, if I'm really able to do it correctly) is
to use antialising when filling text clip pathes with pattern colorspace.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the Poppler-bugs mailing list