Bug 42161 - pdftoppm: spams "Bogus memory allocation size" with antialiasing disabled
Summary: pdftoppm: spams "Bogus memory allocation size" with antialiasing disabled
Status: RESOLVED MOVED
Alias: None
Product: poppler
Classification: Unclassified
Component: utils (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-24 06:32 UTC by Fabian Henze
Modified: 2018-08-20 21:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
The problematic PDF (1.54 MB, application/pdf)
2011-10-24 06:32 UTC, Fabian Henze
Details

Description Fabian Henze 2011-10-24 06:32:35 UTC
Created attachment 52689 [details]
The problematic PDF

Hi,
I have have a problem with pdftoppm from poppler 0.18.0 and 0.16.7 (and probably others as well). When trying to convert a pdf to ppm with:
$ pdftoppm -aa no myfile.pdf folder/foobar
it spams the terminal with "Bogus memory allocation size".

Let me know if I can provide you with any debugging information.
The concerning PDF is attached.

Regards,
Fabian Henze
Comment 1 Albert Astals Cid 2011-10-24 06:54:09 UTC
This is the desired behaviour, the warning is there to warn you something weird happened, in this case due to you not wanting aa there are some characters (for example the - of the exponents in page 8) are missing. If you want we can improve the error message.
Comment 2 Fabian Henze 2011-10-24 07:23:52 UTC
I see,
A descriptive error message would be very nice :)
"bogus memory allocation size" sounds like an application bug.
But why do these characters vanish with aa disabled? How can that be desired behaviour?
Comment 3 Albert Astals Cid 2011-10-24 07:40:40 UTC
Noone said it is the desired behaviour. But it is what happens when you ask freetype to render that character with that font size without antialias, not much we can do if you choose to render without antialias, right?
Comment 4 Fabian Henze 2011-10-24 11:04:42 UTC
(In reply to comment #3)
> Noone said it is the desired behaviour. But it is what happens when you ask
> freetype to render that character with that font size without antialias, not
> much we can do if you choose to render without antialias, right?

What about a "-aa little" setting which renders everything without aa, except for characters which can not be rendered without?
Comment 5 Albert Astals Cid 2011-10-27 07:39:48 UTC
Sincerely, no, you asked for no aa and we did no aa, you might argue we should not loose characters, and I might even agree, but if you ask me it is a freetype bug that they return "empty" characters for when we ask mono rendering of the character. You might file a bug in their bug tracker if they have one.
Comment 6 Daniel Stone 2018-08-20 21:41:25 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/37.


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.