Arg, my last email was bitten by the KMail truncation bug.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057758
You will need to view the HTML version to see the whole thing.
On Tuesday, February 27, 2024 7:47:11 AM MST Soren Stoutner wrote:
> Nathan,
>
> Your comments into why a font would want to change its name were insightful.
>
> On Tuesday, February 27, 2024 5:35:58 AM MST Nathan Willis wrote:
> > That being said, if the existing build script produces a font binary that
> > is functionally identical to the font binaries (a different test than
> > bit-for-bit identical), I believe that's enough, and if future updates to
> > Adobe's own tools make that no longer hold true, I'm confident they would
> > consider that a bug that needed fixing.
>
> This is what SIL’s website says about rebuilding the fonts.
>
> https://openfontlicense.org/how-to-modify-ofl-fonts/[1]
>
> "5.9 Do font rebuilds require a name change? Do I have to change the name of
> the font when my packaging workflow includes a full rebuild from source?"
>
> "Yes, all rebuilds which change the font data and the smart code are Modified
> Versions and the requirements of the OFL apply: you need to respect what the
> Author(s) have chosen in terms of Reserved Font Names. However if a package
> (or installer) is simply a wrapper or a compressed structure around the final
> font - leaving them intact on the inside - then no name change is required.
> Please get in touch with the author(s) and copyright holder(s) to inquire
> about the presence of font sources beyond the final font file(s) and the
> recommended build path. That build path may very well be non-trivial and hard
> to reproduce accurately by the maintainer. If a full font build path is made
> available by the upstream author(s) please be aware that any regressions and
> changes you may introduce when doing a rebuild for packaging purposes is your
> responsibility as a package maintainer since you are effectively creating a
> separate branch. You should make it very clear to your users that your
> rebuilt version is not the canonical one from upstream.”
>
> Does anyone know any way to check if the fonts have the same “font data” in
> any other way besides checking if they are bit-for-bit identical?
>
> In describing this problem, the wiki says the following:
>
> https://wiki.debian.org/Fonts/Bugs/rfn-violation[2]
>
> "The fonts seems to be modified, or has been rebuilt in a way that is
> not bitwise identical to the upstream build, and your font name
> includes Reserved Font Names (RFN) stated in the license."
>
> > > The more I think about this, unless I am somehow able to get Adobe to
> > > authorize a rebuild exception (does anyone have example text of what they
> > > would need to add to the license to do this?), the best way forward might
> > > be
> > > the following:
> > >
> > > "Build the font from source using tools from Debian main during the
> > > package
> > > build but distribute the upstream build in the binary package instead. In
> > > this
> > > case it is not required to move the font to contrib.”
> >
> > I'm not sure I understand what this is proposing. Perhaps someone else who
> > has a longer memory with how RFNs intersect with Debian policy should speak
> > to it, though.
>
> The above wiki page proposes five ways to handle OFL fonts with a Reserved
> Font Name.
--
Soren Stoutner
soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.