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:
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
On Tue, 24 Jan 2023, fab...@greffrath.com wrote:
> 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
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
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
Hi fabian!
On Tue, 24 Jan 2023, fab...@greffrath.com wrote:
> 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
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?
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
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
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
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
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,
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
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 OpenPGP: 0x997A9F17ED7DAEA6
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
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
>
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
> 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
Hi fabian!
On Fri, 20 Jan 2023, fab...@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
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
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
> 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
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
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
>
> "f" == fabian 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
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
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
Package: fonts-urw-base35
Version: 20200910-6
Severity: important
X-Debbugs-Cc: jorge.moral...@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
28 matches
Mail list logo
