Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[Roland Rosenfeld <roland@debian.org>]

On Fri, 20 Jan 2023, Roland Rosenfeld wrote:

> Anyway, it still may be a good idea to run the t1 file through
> t1binary(1) at build time to add this 80 01 91 03 00 00 header.
> 
> So I tried so in
> https://salsa.debian.org/roland/fonts-urw-base35/-/commits/t1binary
> which I expected to work in the same way as 20200910-6 does, but I had
> to notice, that my above mentioned xfig test fails with century
> schoolbook font now sometimes (okay, I reproduced this multiple times
> while switching between -6 and my -7, but now I cannot reproduce the
> issue any longer with my -7, maybe I should pause and try this out
> later (maybe on a different machine)...

In the meantime I noticed, that the above branch isn't a good idea,
since
 t1binary C059-Italic.t1
results in an broken font.
 t1lint C059-Italic.t1
on the _converted_ font reports
 While interpreting 'uni04AE':
  command 19: stack underflow in 'hstem'

This is because t1utils fails on C059-Italic.t1.  I just reported this
as a bug in t1utils: #1029289.

> PS: Just noticed, that the build pipeline of my above t1binary
>     branch fails because the converted C059-Italic.t1 now triggers the
>     flowing warning:
>     "cp1252 "\x90" does not map to Unicode at
>     /usr/share/lintian/lib/Lintian/Check/Fonts/Postscript/Type1.pm
>     line 57."
>     (whatever this means, maybe some bug in lintian).

This problem is also triggered by t1utils fails on the C059-Italic.t1
font.  This time
 t1disasm C059-Italic.t1
contains some parts of the font as binary in the disasm output (which
is expected to be clean ascii), which results in the above lintian
failure.

Greetings
Roland