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: [email protected]
For additional commands, e-mail: [email protected]
