Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1133793 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Jorge Moraleda <jorge.moraleda@gmail.com> - 2023-01-18 20:40 +0100
    Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" fabian@greffrath.com - 2023-01-19 09:20 +0100
      Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" fabian@greffrath.com - 2023-01-19 09:40 +0100
        Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" James Cloos <cloos@jhcloos.com> - 2023-01-19 19:20 +0100
          Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-20 11:30 +0100
    Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Jorge Moraleda <jorge.moraleda@cytopar.com> - 2023-01-19 20:10 +0100
      Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Fabian Greffrath <fabian@debian.org> - 2023-01-20 08:10 +0100
        Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-20 12:00 +0100
          Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" fabian@greffrath.com - 2023-01-20 12:10 +0100
            Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-20 16:10 +0100
              Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-20 20:00 +0100
    Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Jorge Moraleda <jorge.moraleda@cytopar.com> - 2023-01-20 19:10 +0100
      Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-20 23:10 +0100
        Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" James Cloos <cloos@jhcloos.com> - 2023-01-21 01:10 +0100
          Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" James Cloos <cloos@jhcloos.com> - 2023-01-21 19:20 +0100
        Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Fabian Greffrath <fabian@debian.org> - 2023-01-21 20:40 +0100
          Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-22 14:50 +0100
            Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" fabian@greffrath.com - 2023-01-23 12:10 +0100
              Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-23 14:30 +0100
                Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" fabian@greffrath.com - 2023-01-23 14:40 +0100
    Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-23 18:30 +0100
      Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" fabian@greffrath.com - 2023-01-24 08:40 +0100
        Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-24 11:50 +0100
          Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" fabian@greffrath.com - 2023-01-24 12:00 +0100
          Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" fabian@greffrath.com - 2023-01-24 12:10 +0100
            Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-24 14:00 +0100
              Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" fabian@greffrath.com - 2023-01-24 14:30 +0100
                Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing" Roland Rosenfeld <roland@debian.org> - 2023-01-24 14:50 +0100

Page 1 of 2  [1] 2  Next page →

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

Package: fonts-urw-base35
Version: 20200910-6
Severity: important
X-Debbugs-Cc: jorge.moraleda@gmail.com

Dear Maintainer,

I use fonts as part of a java application I develop. I recently upgraded my
system (to an up-to-date debian bookworm).

After this upgrade all fonts packaged in this packet are unloadable by apache
pdfbox (but fonts in the many other font packages that I have installed all
load fine). This is the relevant portion of the logs showing the error (I am
including logs for the error when loading font "NimbusSans-BoldItalic.pfb" but
logs for other fonts in the package are the same)

[2023-01-18 13:15:26] [info] 2023-01-18 13:15:26.561  WARN 228307 --- [alina-
utility-1] o.a.p.p.f.FileSystemFontProvider         : Could not load font file:
/usr/share/fonts/X11/Type1/NimbusSans-BoldItalic.pfb
[2023-01-18 13:15:26] [info] java.io.IOException: Start marker missing
[2023-01-18 13:15:26] [info] #011at
org.apache.fontbox.pfb.PfbParser.parsePfb(PfbParser.java:147)
[2023-01-18 13:15:26] [info] #011at
org.apache.fontbox.pfb.PfbParser.<init>(PfbParser.java:115)
[2023-01-18 13:15:26] [info] #011at
org.apache.fontbox.type1.Type1Font.createWithPFB(Type1Font.java:54)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addType1Font(FileSystemFontProvider.java:790)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.scanFonts(FileSystemFontProvider.java:391)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.<init>(FileSystemFontProvider.java:361)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.<clinit>(FontMapperImpl.java:141)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:160)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:430)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:393)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:367)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.PDType1Font.<init>(PDType1Font.java:146)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.PDType1Font.<clinit>(PDType1Font.java:79)


I am using apache pdfbox version 2.0.27
(https://mvnrepository.com/artifact/org.apache.pdfbox/pdfbox)

I am not familiar with fonts, but according to the source code
(https://github.com/apache/pdfbox/blob/trunk/fontbox/src/main/java/org/apache/fontbox/pfb/PfbParser.java)
it appears that pdfbox expects the font files in pfb format to start with
character 0x80 but they do not.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (800, 'testing'), (50, 'experimental'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fonts-urw-base35 depends on:
ii  xfonts-utils  1:7.7+6

fonts-urw-base35 recommends no packages.

Versions of packages fonts-urw-base35 suggests:
ii  fonts-freefont-otf  20120503-10
ii  fonts-freefont-ttf  20120503-10
ii  fonts-texgyre       20180621-6

-- no debconf information

[toc] | [next] | [standalone]

#1133843

control: severity -1 minor

Hi Jorge,

Am 18.01.2023 20:37, schrieb Jorge Moraleda:
> [2023-01-18 13:15:26] [info] 2023-01-18 13:15:26.561  WARN 228307 --- 
> [alina-
> utility-1] o.a.p.p.f.FileSystemFontProvider         : Could not load 
> font file:
> /usr/share/fonts/X11/Type1/NimbusSans-BoldItalic.pfb

well, as outlined in the package's NEWS file [1], upstream has decided 
to rename the binary font files and in that course change the file 
extensions from .pfb to .t1.

[1] 
https://sources.debian.org/src/fonts-urw-base35/20200910-6/debian/NEWS/

> I am not familiar with fonts, but according to the source code
> (https://github.com/apache/pdfbox/blob/trunk/fontbox/src/main/java/org/apache/fontbox/pfb/PfbParser.java)
> it appears that pdfbox expects the font files in pfb format to start 
> with
> character 0x80 but they do not.

I can see two alternatives how you could solve your problem here:

1) Convince pdfbox upstream that .t1 is a reasonable file extension for 
a binary Type 1 font file and in fact means the same as .pfb.

2) Introduce some symlinks with .pfb extensions pointing to the file 
with the .t1 extension.

A third alternative would be to rename the font files back to .pfb 
extension, but that would be against upstream's will and is thus out of 
question for the Debian package.

  - Fabian

[toc] | [prev] | [next] | [standalone]

#1133844

Am 19.01.2023 08:59, schrieb fabian@greffrath.com:
> 1) Convince pdfbox upstream that .t1 is a reasonable file extension
> for a binary Type 1 font file and in fact means the same as .pfb.

NB: The file command reveals some subtle differences between both 
formats that pdfbox probably isn't aware of:

$ file *
NimbusRoman-BoldItalic.t1: PostScript Type 1 font text 
(NimbusRoman-BoldItalic 1.00)
n022004l.pfb:              PostScript Type 1 font program data 
(NimbusMonL-Bold 1.06)

  - Fabian

[toc] | [prev] | [next] | [standalone]

#1133917

>>>>> "f" == fabian  <fabian@greffrath.com> writes:

f> NB: The file command reveals some subtle differences between both
f> formats that pdfbox probably isn't aware of:

f> $ file *
f> NimbusRoman-BoldItalic.t1: PostScript Type 1 font text
f> (NimbusRoman-BoldItalic 1.00)
f> n022004l.pfb:              PostScript Type 1 font program data
f> (NimbusMonL-Bold 1.06)

that eans that those t1 files are pfa rather than pfb.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

[toc] | [prev] | [next] | [standalone]

#1133983

> f> $ file *
> f> NimbusRoman-BoldItalic.t1: PostScript Type 1 font text
> f> (NimbusRoman-BoldItalic 1.00)
> f> n022004l.pfb:              PostScript Type 1 font program data
> f> (NimbusMonL-Bold 1.06)

> that eans that those t1 files are pfa rather than pfb.

I think that file(1) is wrong here.  The t1 files are binary (pfb), just
look into them using less the like.  There is a text header and than a
binary blob follows.

In contrast to this, text fonts (pfa) use hex encoding instead of 8bit
binary data.

I just tried out with
$ t1binary NimbusSans-BoldItalic.t1 foo.pfb
$ t1ascii NimbusSans-BoldItalic.t1 foo.pfa

And than have a look at the file sizes:
249527 foo.pfa
123322 foo.pfb
123308 NimbusSans-BoldItalic.t1

So converting t1 to pfb implies a minimal size change, while
converting it to pfa duplicates the size.

But the minimal size change seems to make file(1) program happy:

foo.pfa:                  PostScript Type 1 font text (NimbusSans-BoldItalic 1.10)
foo.pfb:                  PostScript Type 1 font program data
NimbusSans-BoldItalic.t1: PostScript Type 1 font text (NimbusSans-BoldItalic 1.10)

since the .pfb file has this little binary header:
00000000  80 01 91 03 00 00 25 21  50 53 2d 41 64 6f 62 65  |......%!PS-Adobe|
00000010  46 6f 6e 74 2d 31 2e 30  3a 20 4e 69 6d 62 75 73  |Font-1.0: Nimbus|
00000020  53 61 6e 73 2d 42 6f 6c  64 49 74 61 6c 69 63 20  |Sans-BoldItalic |
00000030  31 2e 31 30 0a 25 25 43  72 65 61 74 69 6f 6e 44  |1.10.%%CreationD|

which is missing in the .t1 file:
00000000  25 21 50 53 2d 41 64 6f  62 65 46 6f 6e 74 2d 31  |%!PS-AdobeFont-1|
00000010  2e 30 3a 20 4e 69 6d 62  75 73 53 61 6e 73 2d 42  |.0: NimbusSans-B|
00000020  6f 6c 64 49 74 61 6c 69  63 20 31 2e 31 30 0a 25  |oldItalic 1.10.%|
00000030  25 43 72 65 61 74 69 6f  6e 44 61 74 65 3a 20 54  |%CreationDate: T|

Maybe it would be an option to use t1binary to convert all the .t1
files and add the "80 01 91 03 00 00" header to make file(1) and
pdfbox happy?

Greetings
Roland

[toc] | [prev] | [next] | [standalone]

#1133922

[Multipart message — attachments visible in raw view] — view raw

Hello Fabian and James,

Thank you for looking into this.

I remark that the symbolic links created in the *"X11/Type1" *folder change
the file extension of the original file. In particular:

> > file /usr/share/fonts/X11/Type1/NimbusSans-BoldItalic.pfb
> /usr/share/fonts/X11/Type1/NimbusSans-BoldItalic.pfb: symbolic link to
> ../../type1/urw-base35/NimbusSans-BoldItalic.t1
>
(Notice the origin file has extension *"t1"* but the symbolic link changes
that to *"pfb"*)

Is this change intentional?

It appears pdfbox is using the extension to determine the file type because
renaming the symbolic link to preserve the "t1" extension in the symbolic
link fixes the problem.

Fabian mentioned that *"upstream has decided to rename the binary font
files and in that course change the file extensions from .pfb to .t1." *but
from the above experiment it seems that upstream changed the actual file
format, and then they changed the file extensions to match the new format.

IMHO opinion, the solution would be to either not create the symbolic links
or to preserve the original names including the extension. I don't know
enough to know what is best.

[toc] | [prev] | [next] | [standalone]

#1133967

[Multipart message — attachments visible in raw view] — view raw

Hi,

Am Donnerstag, dem 19.01.2023 um 13:57 -0500 schrieb Jorge Moraleda:
> Fabian mentioned that "upstream has decided to rename the binary font
> files and in that course change the file extensions from .pfb to
> .t1." but from the above experiment it seems that upstream changed
> the actual file format, and then they changed the file extensions to
> match the new format.

to be honest, I wasn't even aware of the format change until yesterday.

> IMHO opinion, the solution would be to either not create the symbolic
> links or to preserve the original names including the extension. I
> don't know enough to know what is best.

The symlinks were introduced to facilitate the transition from the
gsfonts package, which had its fonts installed in these directories
with these exact file names. Maybe it makes sense to remove them again
immediately after the next Debian stable release to prevent subtle bugs
like this. @roland what do you think?

 - Fabian

[toc] | [prev] | [next] | [standalone]

#1133993

[Multipart message — attachments visible in raw view] — view raw

Hi Fabian!

On Fri, 20 Jan 2023, Fabian Greffrath wrote:

> Am Donnerstag, dem 19.01.2023 um 13:57 -0500 schrieb Jorge Moraleda:
> > Fabian mentioned that "upstream has decided to rename the binary font
> > files and in that course change the file extensions from .pfb to
> > .t1." but from the above experiment it seems that upstream changed
> > the actual file format, and then they changed the file extensions to
> > match the new format.
> 
> to be honest, I wasn't even aware of the format change until yesterday.

Me too.  But as I wrote in my previous mail, this wasn't a change from
binary to ascii but only the 4 bytes that make file(1) think that it
is a binary font at the beginning of the file are missing now... 

> > IMHO opinion, the solution would be to either not create the symbolic
> > links or to preserve the original names including the extension. I
> > don't know enough to know what is best.

> The symlinks were introduced to facilitate the transition from the
> gsfonts package, which had its fonts installed in these directories
> with these exact file names. Maybe it makes sense to remove them
> again immediately after the next Debian stable release to prevent
> subtle bugs like this. @roland what do you think?

I'm not sure why we used .pfb in these symlinks (and in
fonts-urw-base35.scale) instead of .t1 extension.
Except this the symlinks are there because the X11 font path by
default point to
 /usr/share/fonts/X11/misc,
 /usr/share/fonts/X11/cyrillic,
 /usr/share/fonts/X11/100dpi/:unscaled,
 /usr/share/fonts/X11/75dpi/:unscaled,
 /usr/share/fonts/X11/Type1,
 /usr/share/fonts/X11/100dpi,
 /usr/share/fonts/X11/75dpi,
 built-ins

If we want to make fonts available to X11 we have to put them into
these paths (especially /usr/share/fonts/X11/Type1) place the
<package>.scale file into /etc/X11/fonts/Type1/ and run
 update-fonts-scale Type1;update-fonts-dir --x11r7-layout Type1;\
 update-fonts-alias --include /etc/X11/fonts/Type1/fonts-urw-base35.alias Type1
(via dh_installxfonts) in postinst to make all this available to the
font server.

So from my point of view we shouldn't remove the symlinks (since we
want to use these fonts in X11) but we should change the symlink
filenames from .pfb to .t1 and change urw-fonts-base35.scale
accordingly (hope that this works as expected, since I didn't try this
out yet).

Greetings
Roland

[toc] | [prev] | [next] | [standalone]

#1134002

Am 20.01.2023 11:49, schrieb Roland Rosenfeld:
> So from my point of view we shouldn't remove the symlinks (since we
> want to use these fonts in X11) but we should change the symlink
> filenames from .pfb to .t1 and change urw-fonts-base35.scale
> accordingly (hope that this works as expected, since I didn't try this
> out yet).

Alright, sounds like a reasonable plan to me. At least more reasonable 
than a format conversion at package build time. ;)

Thanks!

  - Fabian

[toc] | [prev] | [next] | [standalone]

#1134040

[Multipart message — attachments visible in raw view] — view raw

Hi fabian!

On Fri, 20 Jan 2023, fabian@greffrath.com wrote:

> Am 20.01.2023 11:49, schrieb Roland Rosenfeld:
> > So from my point of view we shouldn't remove the symlinks (since we
> > want to use these fonts in X11) but we should change the symlink
> > filenames from .pfb to .t1 and change urw-fonts-base35.scale
> > accordingly (hope that this works as expected, since I didn't try this
> > out yet).
> 
> Alright, sounds like a reasonable plan to me. At least more
> reasonable than a format conversion at package build time. ;)

Sadly it sounds much better than it really works.
I tried this out in
https://salsa.debian.org/roland/fonts-urw-base35/-/tree/t1 and the
resulting package doesn't show the fonts in X11.
(don't forget to run "xset fp rehash" after installing or changing the
package).

A downgrade to fonts-urw-base35 20200910-6 solves the issue.

So X11 seems to be unable to handle the fonts if their file suffix is
neither .pfa or .pfb but .t1 :-(

If you try to reproduce my tests, I attached fonts-portrait.fig, which
I open with xfig.  This should show a list of fonts that xfig can
handle, all of them should be scalable and no errors or warnings
should pop up (don't forget the "xset fp rehash" after installing a
different version of fonts-urw-base35).


I searched for some definition that says, that a .pfb file has to
be prefixed with 80 01 91 03 00 00 (in front of %!PS-AdobeFont-1.),
but didn't find such a specification.
https://git.in-ulm.de/cbiedl/file/src/master/magic/Magdir/fonts
refers to http://mark0.net/download/triddefs_xml.7z defs/p/pfb.trid.xml,
which defines the following pattern
        <FrontBlock>
                <Pattern>
                        <Bytes>8001</Bytes>
                        <Pos>0</Pos>
                </Pattern>
                <Pattern>
                        <Bytes>00002521</Bytes>
                        <ASCII> . . % !</ASCII>
                        <Pos>4</Pos>
                </Pattern>
        </FrontBlock>
for pfb-files, but this isn't a specification but only some trial to
identify pfb files...

In the T1 font format specification
https://web.archive.org/web/20150321034514/http://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF
I don't find anything about pfb especially not about some 0x8001 file
prefix.


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)...

But I send this mail out now, maybe my "results" can help somebody
with his further research...

Greetings
Roland

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).

[toc] | [prev] | [next] | [standalone]

#1134092

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

[toc] | [prev] | [next] | [standalone]

#1134084

[Multipart message — attachments visible in raw view] — view raw

> I searched for some definition that says, that a .pfb file has to
> be prefixed with 80 01 91 03 00 00 (in front of %!PS-AdobeFont-1.),
> but didn't find such a specification.

I found this in case it helps
https://personal.math.ubc.ca/~cass/piscript/type1.pdf

[toc] | [prev] | [next] | [standalone]

#1134124

On Fri, 20 Jan 2023, Jorge Moraleda wrote:

> > I searched for some definition that says, that a .pfb file has to
> > be prefixed with 80 01 91 03 00 00 (in front of %!PS-AdobeFont-1.),
> > but didn't find such a specification.

> I found this in case it helps
> https://personal.math.ubc.ca/~cass/piscript/type1.pdf

That's quite interesting.  Chapter 1 of this document explains, that
.pfb files have multiple of these "segment headers" but I miss them in
the fonts-urw-base35 .t1 fonts (not only at the beginning of the file,
but also at the beginning of the binary part as well as at the end of
the binary part).

It's not possible to simply prefix the .t1 files with 6 bytes, since
the other headers have to be added, too, and byte 3-6 of each header
contains the segment size.

But for me it seems that the .t1 files are neither .pfa files (since
they contain binary content, which isn't ascii armored) nor .pfb files
(since the segment headers are missing).

So we should think about "repairing" these files and make them real
.pfb files with segment headers.  Only problem is, that t1binary
doesn't handle C059-Italic.t1 correctly but generates a completely
broken font file.

So I did some perl hacking and created a addsegmentheaders.pl, which
adds segment headers at the beginning of the file, at the beginning of
the binary data and at the end.

First tests with the patched files look good, but someone else should
have a look on this...

You find my changes in my segmentheaders branch:
https://salsa.debian.org/roland/fonts-urw-base35/-/tree/segmentheaders

Next problem: lintian complains about

E: fonts-urw-base35: license-problem-font-adobe-copyrighted-fragment-no-credit [usr/share/fonts/type1/urw-base35/C059-BdIta.t1]
N: 
N:   This type 1 font file includes some postscript fragment with a non-free
N:   license of Adobe. In order to check if this tag is genuine please follow
N:   the procedure described in the reference.
N:   
N:   Moreover the fragment was likely verbatim copied from black book without
N:   any credit to Adobe.
N:   
N:   Should this be a false-positive, please override the tag.
N: 
N:   Please refer to https://wiki.debian.org/qa.debian.org/type1nondfsg for
N:   details.
N: 
N:   Visibility: error
N:   Show-Always: no
N:   Check: fonts/postscript/type1
N

for all the fonts now.  This is because the disassembled code contains
"startlock get exec" which may be a fragment from Adobe
from the following book:
https://web.archive.org/web/20150321034514/http://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF
Appendix 3, page 95 (of the book) page 101 (of the PDF).

It wasn't tested before, since the file type wasn't detected as
"PostScript Type 1 font program data" before, so lintian didn't check
the files...

Greetings
Roland

[toc] | [prev] | [next] | [standalone]

#1134140

having looked at one of those .t1 files now, i see that it is indeed a
new file format.

the plrm notes that eexec can handle either hex or binary data
transparently, and that is the only difference from traditional
pfa i can see.

so they saved some disk size and some memory pressure compared to pfa.

it should be possible these days to embed those files as is into a
postscript file, given that transmission is likely to be over ip or usb.
(unlike, say, rs232 with xon/xoff.)

software which expects pfa or pfb should learn to hadle these, too.

freetype has no problem with them.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

[toc] | [prev] | [next] | [standalone]

#1134226

oh, and one way to convert the .t1 to traditional pfa or pfb is like this:

t1disasm …/urw-base35/NimbusRoman-Bold.t1|t1asm -b -o NimbusRoman-Bold.pfb

(or -a for .pfa).

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

[toc] | [prev] | [next] | [standalone]

#1134240

[Multipart message — attachments visible in raw view] — view raw

Hi Roland,

thank you very much for the effort you put into this issue!

Am Freitag, dem 20.01.2023 um 23:03 +0100 schrieb Roland Rosenfeld:
> So we should think about "repairing" these files and make them real
> .pfb files with segment headers.  Only problem is, that t1binary

We must not forget the primary purpose of these fonts, and that is to
serve as the 35 base fonts for ghostscript! Thus, I consider it out of
question to modify the original T1 fonts in this package.

What we may discuss about is to replace the "compatibility symlinks" in
/usr/share/fonts/X11/Type1 with actual converted PFB files.

> doesn't handle C059-Italic.t1 correctly but generates a completely
> broken font file.

Does it work if you first convert to PFA format and from there to PFB
format?

 - Fabian

[toc] | [prev] | [next] | [standalone]

#1134352

On Sat, 21 Jan 2023, James Cloos wrote:

> oh, and one way to convert the .t1 to traditional pfa or pfb is like this:
> 
> t1disasm …/urw-base35/NimbusRoman-Bold.t1|t1asm -b -o NimbusRoman-Bold.pfb

Except that this does not work for C059-Italic.t1 (see
https://bugs.debian.org/1029289).


On Sat, 21 Jan 2023, Fabian Greffrath wrote:

> We must not forget the primary purpose of these fonts, and that is to
> serve as the 35 base fonts for ghostscript! Thus, I consider it out of
> question to modify the original T1 fonts in this package.
> 
> What we may discuss about is to replace the "compatibility symlinks" in
> /usr/share/fonts/X11/Type1 with actual converted PFB files.

That would be an option.  But X11 works for me with the symlinks
without problems (it's only necessary that they are named .pfb not
.t1).

So from a "requirement" point of view it's only pdfbox, which fails on
.pfb files without the binary segment headers (and t1utils, which
fails with C059-Italic.t1, which can be repaired with my segmentheader
generator script).

> > doesn't handle C059-Italic.t1 correctly but generates a completely
> > broken font file.

> Does it work if you first convert to PFA format and from there to PFB
> format?

No,
 t1ascii C059-Italic.t1 | t1binary | t1disasm
still has a binary blob (near definition of /uni0496).

So t1utils are not able to handle C059-Italic.t1 at all (unless this
font is patched with segment headers using my script before).

I just compared the output of t1disasm of the original .t1 fonts and
my patched fonts and noticed that the result is identical except
C059-Italic.t1 and P052-italic.t1, which both have (unexpected) binary
data in their disassembled output.


I understand, that you do not want to modify the official urw-base35
.t1 fonts, since FreeType is able to handle them as they are, but from
robustness principle view
(https://en.wikipedia.org/wiki/Robustness_principle)
"be conservative in what you send, be liberal in what you accept",
it may be a good idea to "convert" the .t1 fonts to .pfb fonts by
adding thes segment headers (and maybe rename them to .pfb), so all
software (not only FreeType) is able to use them...

Because there is other software, that doesn't support the fonts as
they are:
- X11 does not accept the .t1 suffix
- pdfbox does not accept .t1 suffix and missing segment headers
- t1utils fails on missing segment headers on C059-Italic.t1 and
  P052-italic.t1

So the current .t1 fonts are not really conservative...

Greetings
Roland

[toc] | [prev] | [next] | [standalone]

#1134498

Am 22.01.2023 14:43, schrieb Roland Rosenfeld:
> So the current .t1 fonts are not really conservative...

No, they are not really conservative, but they are exactly what was 
given by us from Artifex to use with Ghostscript. And I wouldn't want to 
put this tight relation between ghostscript and the fonts at risk in the 
course of fixing the fonts for less related software.

I'd still agree, though, to replace the compatiblity symlinks with 
patched and fixed variants.

  - Fabian

[toc] | [prev] | [next] | [standalone]

#1134522

Hi fabian!

On Mon, 23 Jan 2023, fabian@greffrath.com wrote:

> I'd still agree, though, to replace the compatiblity symlinks with
> patched and fixed variants.

Okay, I created another test branch:
https://salsa.debian.org/roland/fonts-urw-base35/-/tree/fixedpfb
that keeps the unchanged .t1 fonts in usr/share/fonts/type1/urw-base35
and places files with added section headers to
/usr/share/fonts/X11/Type1 (instead of the former symlinks).

This still doesn't solve the lintian error complaining about
license-problem-font-adobe-copyrighted-fragment-no-credit in the .pfb
files, because "startlock get exec" can be found in the t1disasm
output.

Greetings
Roland

[toc] | [prev] | [next] | [standalone]

#1134526

Hi Roland,

Am 23.01.2023 14:18, schrieb Roland Rosenfeld:
> Okay, I created another test branch:

that'd be fine with me, thanks!

Would it make sense to disassemble and reassemble the newly created 
files as some sort of additional smoke test?

Cheers,
  - Fabian

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web