Mon 22 Nov 2010 06:08:29 PM UTC, comment #10:
Thanks for very quick reply!
Here I close this bug.
|
Mon 22 Nov 2010 06:02:03 PM UTC, comment #9:
Looks to work fine, thanks a lot :-D
|
Mon 22 Nov 2010 05:56:26 PM UTC, comment #8:
Attached patch is committed to GIT head.
Please test.
(file #22079)
|
Tue 16 Nov 2010 09:27:48 AM UTC, comment #7:
Thanks in advance for working on this!
|
Tue 16 Nov 2010 08:39:27 AM UTC, comment #6:
Yes. To identify problematic fonts by cvt/prep/fpgm checksum,
we have to calculate checksum by ourselves. At present, the
fonts bundled to Microsoft Office for MacOS have correct
checksum, so we can do that.
# if we find some problematic fonts with invalid checksum,
# we have to calculate the checksum always by ourselves
# even if a font provide them.
Now I'm changing my patch to do it. Unfortunately, I have no skill
to write the assembler version of checksum calculator, the faster
version requires a few weeks...
|
Tue 16 Nov 2010 08:23:39 AM UTC, comment #5:
> Furthermore, in the TrueType fonts embedded by Quartz
> PDFContext, all tables lack their checksum. Oops.
This basically means that your idea of using cvt checksums fails, right?
|
Tue 16 Nov 2010 06:51:43 AM UTC, comment #4:
BTW, the creator of the PDF showing this "regression" is
"Quartz PDFContext", a generic framework in Mac OS X
to generate PDF instead of the printing document.
There might be long history that people were asking for
the improvement of its feature to generate well-mannered
PDF, but still the history is ongoing...
On Mac OS X, the genuine TTF for Times Roman is
/System/Library/Fonts/Times.dfont. When Microsoft Office
is installed, /Library/Fonts/Microsoft/Times New Roman.ttf
is added too. Times.dfont doesn't have gasp, but Times New
Roman.ttf has gasp. When I generate a PDF via Microsoft
Word, the gasp table for embedded "Times New Roman" is
removed, as Werner had pointed out.
Furthermore, in the TrueType fonts embedded by Quartz
PDFContext, all tables lack their checksum. Oops.
|
Mon 15 Nov 2010 04:59:44 AM UTC, comment #3:
Hi Pachu,
I'm sorry for my change to force hinting for the embedded font
without familyname made you disappointed. For the background
of the change, please find the dicussion in poppler mailing list
and freetype-devel mailing list:
http://lists.freedesktop.org/archives/poppler/2010-August/006271.html
http://lists.nongnu.org/archive/html/freetype-devel/2010-08/msg00020.html
It was for a Traditional Chinese font bundled to Microsoft Windows.
--
In the participants of the discussion, enabling hints for nameless
font objects in PDF was agreed to be the simplest solution.
However, I expected the comments like "hinted result is worse
for the font XXX, don't enable hinter!" could be posted.
I've ever drafted a way to restrict the hinter to the problematic
fonts without family name.
http://lists.nongnu.org/archive/html/freetype-devel/2010-08/msg00019.html
I can replace the current solution ("nameless font is hinted") by
this one. Werner, what do you think about?
|
Mon 15 Nov 2010 01:00:11 AM UTC, comment #2:
It's not a regression per se. This rendering difference is probably caused by git commit 0eb9b1f5:
Force hinting when the font lacks its familyname.
For testing purposes, I've extracted font RWNLNK+TimesNewRomanPSMT from the sample PDF file. Note that it displays fine if you use non-AA rendering. However, this subfont lacks a `gasp' table – the original fonts (as distributed by Windows) do have one. Basically, I consider this a bug in the PDF creator program: Without this table, the PDF viewer has no chance to decide whether to use the hints or not.
I don't know how to proceed. Comments, please.
|
Sat 13 Nov 2010 07:57:24 PM UTC, comment #1:
A file to test can be downloaded from http://bugs.gentoo.org/attachment.cgi?id=251839&action=view
|
Sat 13 Nov 2010 07:54:23 PM UTC, original submission:
Originally reported downstream at:
http://bugs.gentoo.org/show_bug.cgi?id=342515
This is a regression introduced in 2.4.3, downgrading to
2.4.2 solves it.
When I open a pdf using evince or acroread, fonts are shown like "sharpened",
attached screenshots show the issue (if you open them with eog, please disable
"Smooth" when zooming in preferences to prevent it from "hiding" the problem).
|