> On 3 Nov 2016, at 02:11, Maruan Sahyoun <sahy...@fileaffairs.de> wrote:
> 
> Hi,
> 
> a very common issue on the mailing list as well as SO is the 
> IllegalArgumentException people get if one tries to use a character with a 
> font which has no support for that. Could we lower the requirement here to 
> instead of throwing a exception use a replacement char and log a warning? 
> Other ideas?

The existing design of PDFBox assumes a unique unicode char -> glyph mapping 
exists with respect to font embedding. This is because we don’t do any complex 
text layout, so it’s a safe assumption, for now. Note that the mapping of 
“missing unicode char” -> .notdef is not unique if there’s more than one 
missing char, so there’s no simple fix for supporting missing characters with 
even .notdef.

I don’t think we should be silently generating broken PDFs - nobody benefits 
from such a PDF. Dumping the problem on some unfortunate end user further down 
the line is not a solution :)

But we 100% should do something to improve this when we implement complex text 
layout, because that already requires that we abandon the concept of a unique 
char -> glyph mapping and replace it with something more sophisticated. One 
thing this will allow us to solve is the issue of missing whitespace glyphs 
such as tab and nbsp, because we’ll finally be able to map them to a space.

In hindsight, we really should have thrown a checked exception for missing 
glyphs, because IllegalArgumentException causes people to think that PDFBox is 
broken, when in fact the problem is with their code.

— John

> I know that the current behaviour has been introduced to ensure a consistent 
> PDF but it might be a little difficult to handle. 
> 
> BR
> Maruan
> ---------------------------------------------------------------------
> 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

Reply via email to