Bug 95344 - Text sized and positioned incorrectly
Summary: Text sized and positioned incorrectly
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: splash backend (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-10 22:29 UTC by Konstantin Svist
Modified: 2018-05-02 07:29 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
restore the current position also in output device (337 bytes, patch)
2016-05-11 14:24 UTC, Thomas Freitag
Details | Splinter Review

Description Konstantin Svist 2016-05-10 22:29:27 UTC
Using Okular frontend

This is seen on some documents, for instance Chase bank year end statement.

The expected text is on the page but in tiny font and unexpected location (first impression is that the text is missing entirely)
Interestingly, searching for the text highlights blank space in the expected area In contrast, other software (Evince) displays the text correctly

Reproducible: Always

https://bugs.kde.org/show_bug.cgi?id=362765
Comment 1 Thomas Freitag 2016-05-11 11:57:57 UTC
This PDF uses type 3 chars, and somehow the caching of type 3 chars in Splash fails with several:

Syntax Warning: Bad bounding box in Type 3 glyph

I don't completely understand this type of caching in splash, but I see that even if it would work with this PDF, the cached glyphs are never used. And if I remove just the caching of glyphs, it works fine!

Cairo uses the same implementation but it never caches the glyphs, so they are always redrawn.

PSOutput neither uses beginType3Char nor drawChar.

So I think about to remove the type3 glyph caching and do it similar to cairo, but I'm not sure if this cache in splash ever speeds up some rendering and therefore is necessary.
Comment 2 Adrian Johnson 2016-05-11 12:04:41 UTC
(In reply to Thomas Freitag from comment #1)
> Cairo uses the same implementation but it never caches the glyphs, so they
> are always redrawn.

Cairo caches the glyphs within cairo. Always drawing the glyphs would be very slow.
Comment 3 Thomas Freitag 2016-05-11 12:20:29 UTC
(In reply to Adrian Johnson from comment #2)
> (In reply to Thomas Freitag from comment #1)
> > Cairo uses the same implementation but it never caches the glyphs, so they
> > are always redrawn.
> 
> Cairo caches the glyphs within cairo. Always drawing the glyphs would be
> very slow.

??? 
Looking in the implementation of CairoOutputDev::beginType3Char the code of the glyph is not saved or used, it always return gFalse, therefore Gfx calls display for the charProc and the endType3Char always, and CairoOutputDev::endType3Char just restores what is saved in beginType3Char. Is there some magic I don't understand?

On the other hand, I missed that splash indeed uses sometimes the cached glyphs for this PDF, I missed that somehow in my first investigation. And the rendering time increases a little bit 

w using the cache

real	0m0.182s
user	0m0.163s
sys	0m0.021s

w/o using the cache

real	0m0.214s
user	0m0.200s
sys	0m0.018s

So I fear I need some more time for investigation.
Comment 4 Thomas Freitag 2016-05-11 12:27:34 UTC
(In reply to Adrian Johnson from comment #2)
> (In reply to Thomas Freitag from comment #1)
> > Cairo uses the same implementation but it never caches the glyphs, so they
> > are always redrawn.
> 
> Cairo caches the glyphs within cairo. Always drawing the glyphs would be
> very slow.

Forget my comment 3 in case of cairo. Cairo implements CairoOutputDev::beginType3Char and CairoOutputDev::endType3Char, but it is not used because of interpretType3Chars() returns gFalse J
Comment 5 Thomas Freitag 2016-05-11 14:24:18 UTC
Created attachment 123621 [details] [review]
restore the current position also in output device

As in the comment in Gfx.cc in case of using beginType3Char, GfxState::restore() does *not* restore the current position. But of course this is also the case for any output device uses this branch, so we have to update the CTM also in the output device.

This patch does it.
Comment 6 Albert Astals Cid 2016-05-12 22:08:09 UTC
Pushed!
Comment 7 oliver.sander 2018-05-01 20:16:43 UTC
Hi Thomas,

I came across your patch when implementing type3 support for the Arthur backend.  The one line added by your patch makes my seemingly correct type3 implementation fail.  More details can be found in 

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

Looking at your patch got me confused.  It calls updateCTM with an all-zero matrix.  In my understanding of what updateCTM does, this will multiply the current CTM with zero, and all later rendering will be scaled to size zero.  This is indeed what is happening in ArthurOutputDev.

On the other hand, when I revert your patch, I cannot reproduce the original bug that made you write the patch anymore.  I tried with the test file from

  https://bugs.kde.org/show_bug.cgi?id=362765

I get lots of errors saying

  "Error: Save (q) operator before d0/d1 in Type 3 glyph"

but the rendering seems to be okay.  So would it be possible to get some explanation of why you wrote the patch the way you did?  Is my understanding of updateCTM wrong?  Or does your fix need improvements?

Many thanks,
Oliver
Comment 8 oliver.sander 2018-05-01 20:24:29 UTC
PS: I wrote:

"In my understanding of what updateCTM does, this will multiply the current CTM with zero, and all later rendering will be scaled to size zero."

That's not quite correct.  In my understanding, calling updateCTM with all zero will set the scaling and shearing to zero, and leave the displacement untouched.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.