I've fixed the issue in the trun k and the 3.0-branch.
The fix is limited to incorrect CID font definitions.
Let us know if there are any other cases and provide a sample.
Andreas
Am 21.01.24 um 11:23 schrieb Andreas Lehmkühler:
I had a look and found s solution based on the pdf.js implementation.
I'm going to commit it once I've improved the code, for now it is still
some kind of hacky.
And yes, PDFBOX-5704 is related to this proposal.
Please follow up on PDFBOX-5704
@Mike thanks for the valuable input
Andreas
Am 19.01.24 um 08:03 schrieb Andreas Lehmkühler:
Hi,
I'm not sure if both issues are similar. However, your proposal is an
interesting idea and I guess it shouldn't be that hard to implement it.
Thanks for the input, I'm going to have a look.
Andreas
Am 19.01.24 um 04:49 schrieb Mike Li:
Hello team,
I recently encountered the problem that PDFBox cannot render Chinese,
the problem is very similar to
https://issues.apache.org/jira/browse/PDFBOX-5704.
In this case, the attached PDF file embedded a CCF font file, the
correct font type/subtype should be /CIDFontType0 and /CIDFontType0C
and should declare property /FontFile3. But it wrongly declared the
subfont as a truetype, and it makes PDFBox uses TTF parser to parse
the font file stream based on the declared type.
According to the spec, PDFBox does it right, but from the perspective
of use, this looks more like a "bug", though this file would display
good in other most used PDF readers (Adobe, Foxit, pdfjs etc.)
I have many years of working experience in PDF generation (iText,
PDFBox, etc.), and I know that after a PDF is generated, as long as
it can be displayed correctly in Adobe Reader, then it is considered
correct. If another program cannot display it correctly, it will be
considered a bug in other program. It's not fair, but it's reality.
Many low-quality PDF generation tools/libraries are still widely used.
In pdf.js, it will parse the font file first, and prefer the font
type in font file rather than the type declared in font dictionary.
https://github.com/mozilla/pdf.js/blob/1cdbcfef821c7f6e81ea22fe68a8b815bca01c4e/src/core/fonts.js#L1052
So my question is "Is that possible that PDFBox provide some font
processing workaround logic to handle such case?"
Thanks
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
