Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

427 views
Skip to first unread message

Jorge Moraleda

unread,
Jan 18, 2023, 2:40:04 PM1/18/23
to
Package: fonts-urw-base35
Version: 20200910-6
Severity: important
X-Debbugs-Cc: jorge.m...@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

fab...@greffrath.com

unread,
Jan 19, 2023, 3:20:04 AM1/19/23
to
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

fab...@greffrath.com

unread,
Jan 19, 2023, 3:40:04 AM1/19/23
to
Am 19.01.2023 08:59, schrieb fab...@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

James Cloos

unread,
Jan 19, 2023, 1:20:04 PM1/19/23
to
>>>>> "f" == fabian <fab...@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 <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

Jorge Moraleda

unread,
Jan 19, 2023, 2:10:03 PM1/19/23
to
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.

Fabian Greffrath

unread,
Jan 20, 2023, 2:12:43 AM1/20/23
to
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

signature.asc

Roland Rosenfeld

unread,
Jan 20, 2023, 5:30:04 AM1/20/23
to
> 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

Roland Rosenfeld

unread,
Jan 20, 2023, 6:02:29 AM1/20/23
to
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

signature.asc

fab...@greffrath.com

unread,
Jan 20, 2023, 6:10:05 AM1/20/23
to
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

Jorge Moraleda

unread,
Jan 20, 2023, 1:10:04 PM1/20/23
to
> 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.


Roland Rosenfeld

unread,
Jan 20, 2023, 2:00:04 PM1/20/23
to
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

Roland Rosenfeld

unread,
Jan 20, 2023, 5:10:04 PM1/20/23
to
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

James Cloos

unread,
Jan 20, 2023, 7:10:04 PM1/20/23
to
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.

James Cloos

unread,
Jan 21, 2023, 1:20:03 PM1/21/23
to
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).

Fabian Greffrath

unread,
Jan 21, 2023, 2:40:04 PM1/21/23
to
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

signature.asc

Roland Rosenfeld

unread,
Jan 22, 2023, 8:50:04 AM1/22/23
to
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

fab...@greffrath.com

unread,
Jan 23, 2023, 6:10:04 AM1/23/23
to
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

Roland Rosenfeld

unread,
Jan 23, 2023, 8:30:04 AM1/23/23
to
Hi fabian!

On Mon, 23 Jan 2023, fab...@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

fab...@greffrath.com

unread,
Jan 23, 2023, 8:40:04 AM1/23/23
to
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

Roland Rosenfeld

unread,
Jan 23, 2023, 12:30:04 PM1/23/23
to
Hi Fabian!

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

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

Sounds as a good idea to me.
I realized all your suggestions in
https://salsa.debian.org/roland/fonts-urw-base35/-/commit/127df27b

Now we only have to solve the lintian error
license-problem-font-adobe-copyrighted-fragment-no-credit issue...

Greetings
Roland

fab...@greffrath.com

unread,
Jan 24, 2023, 2:40:03 AM1/24/23
to
Hi Roland,

Am 23.01.2023 18:23, schrieb Roland Rosenfeld:
> Now we only have to solve the lintian error
> license-problem-font-adobe-copyrighted-fragment-no-credit issue...

wow, the information given here is not really helpful. What can/should
we do?

https://wiki.debian.org/qa.debian.org/type1nondfsg

- Fabian

Roland Rosenfeld

unread,
Jan 24, 2023, 5:50:05 AM1/24/23
to
Hi fabian!
Legal issues are the horror to me...

I dived into the referenced bug #665334 and read in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665334#173 that
some of the code is based on Adobe Font Development Kit for OpenType
(AFDKO), which is licensed under Apache-2.0 license.
But I didn't compare the code in AFDKO and the urw-base35 fonts so
far.

But it's also possible that urw-base35 is based on an older version of
fontforge, which still has this issue.

So maybe this issue is already solved and lintian has to be
updated/overriden but it's also possible that this issue still
persists and has to be solved by URW.

Maybe some of the contributors of #665334 can assist here?

Greetings
Roland

fab...@greffrath.com

unread,
Jan 24, 2023, 6:00:04 AM1/24/23
to
Hey Roland,

Am 24.01.2023 11:42, schrieb Roland Rosenfeld:
> Legal issues are the horror to me...

yep, me too. I have decided not to become a lawyer for a reasson. ;)

> So maybe this issue is already solved and lintian has to be
> updated/overriden but it's also possible that this issue still
> persists and has to be solved by URW.

Some packages see it quite pragmatically:

https://github.com/debian-tex/lmodern/commit/f2d47ac8cd73f847ef741d20f905165f62916e0b

Cheers,

- Fabian

fab...@greffrath.com

unread,
Jan 24, 2023, 6:10:04 AM1/24/23
to
Wild idea:

The AFDKO is Apache licensed. Would it be possible to install the
afdko-bin package and use its /usr/libexec/afdko/detype1 and
/usr/libexec/afdko/type1 scripts to disassemble and reassemble the font
files? And will this probably replace the code in question with its
Apache licensed pendants?

- Fabian

Roland Rosenfeld

unread,
Jan 24, 2023, 8:00:05 AM1/24/23
to
On Tue, 24 Jan 2023, fab...@greffrath.com wrote:

On a first try I wasn't able to run type1 on the detype1 output (fails
with "bad token in charsting"), but didn't dig deeper with this.


Instead I compared the problematic code fragment 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).

with the output of t1disasm of the urw-base35 fonts.

While the code fragment in the book is 181 lines a diff with one of
the urw-base35 fonts shows only the following copied code lines:

{systemdict /internaldict known not
{pop 3}
{1183615869 systemdict /internaldict get exec
dup /startlock known
{/startlock get exec}
{dup /strtlck known
{/strtlck get exec}
{pop 3}
ifelse}
ifelse}
ifelse
} executeonly
] noaccess def

Since it contains the string "startlock get exec" it triggers the
lintian error.

I searched for the number (1183615869) in afdko source and found the
following file:
https://github.com/adobe-type-tools/afdko/blob/develop/c/shared/source/t1write/t1write_hintothers.h

/* Copyright 2014 Adobe Systems Incorporated (http://www.adobe.com/). All Rights Reserved.
This software is licensed as OpenSource, under the Apache License, Version 2.0.
This license is available at: http://opensource.org/licenses/Apache-2.0. */

"/OtherSubrs[{}{}{}{systemdict/internaldict known not{pop 3}{1183615869\n"
"systemdict/internaldict get exec dup/startlock known{/startlock get exec}{dup\n"
"/strtlck known{/strtlck get exec}{pop 3}ifelse}ifelse}ifelse}executeonly]def\n"


As far as I can see that is exactly the code, that I found in the
urw-base35 fonts and that triggers the lintian error.

And as the header says, it is under Apache 2.0 license.

So lintian is wrong here and we can add lintian-overrides for this.

According to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665334#173
Apache-2.0 should be compatible with GPL-3 (the license of
fonts-urw-base35), so everything should be okay with this.


After fixing some issues in check-fonts-urw-base35-scale and adding
lintian-overrides (after some typos) this may be ready for a merge
request soon...

Greetings
Roland

fab...@greffrath.com

unread,
Jan 24, 2023, 8:30:04 AM1/24/23
to
Hi Sherlock,

Am 24.01.2023 13:47, schrieb Roland Rosenfeld:
> So lintian is wrong here and we can add lintian-overrides for this.

o_O Impressive!

Could you please add a lintian overrides with a reference to this
finding?

And probably file a bug against lintian? I guess this might have some
impact on other packages providing Type1 font files as well.

Thank you very much!

- Fabian

Roland Rosenfeld

unread,
Jan 24, 2023, 8:50:04 AM1/24/23
to
Hi Fabian!

On Tue, 24 Jan 2023, fab...@greffrath.com wrote:

> Hi Sherlock,

:-)

> Could you please add a lintian overrides with a reference to this finding?

I just referenced http://bugs.debian.org/1029555 in the lintian-overrides.

> And probably file a bug against lintian?

Already did so: http://bugs.debian.org/1029555

> I guess this might have some impact on other packages providing
> Type1 font files as well.

Someone should update the wiki page referenced by lintian:
https://wiki.debian.org/qa.debian.org/type1nondfsg
I already replaced the links by links to archive.org (since the
original URLs are no longer existing), but maybe the sentence "Adobe
seems willing to relicense see mail here." should be updated pointing
to
https://github.com/adobe-type-tools/afdko/blob/develop/c/shared/source/t1write/t1write_hintothers.h

But I fear that I could make the page even worse, if I just change
it...

Greetings
Roland
0 new messages