Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Font files licencing #474

Closed
strzibny opened this issue Apr 17, 2013 · 11 comments
Closed

Font files licencing #474

strzibny opened this issue Apr 17, 2013 · 11 comments

Comments

@strzibny
Copy link
Member

Hello guys,

I would like to clarify the license of bundled font files. The *afm font files (like Courier-Bold [1]) references "Copyright (c) 1989, 1990, 1991, 1993, 1997 Adobe Systems Incorporated. All Rights Reserved." and I am unsure if that doesn't clash with licensing of Prawn [2] since Prawn bundles the fonts to a single package.

Can someone explain why is it necessary to bundle them and whether this is legal? Is it not enough for Prawn to use system font files? I want to package Prawn for Fedora and this part has to be clarified before I can continue.

Perhaps @sandal can clarify this? Thank you.

[1] https://github.com/prawnpdf/prawn/blob/master/data/fonts/Courier-Bold.afm
[2] https://github.com/prawnpdf/prawn/blob/master/LICENSE

@bradediger
Copy link
Member

Thank you for raising this issue. After investigating, I believe we are in compliance with the license these files are provided under.

It is necessary to bundle the AFM fonts because they provide font metrics for the "core 14" fonts that PDF readers must support. These fonts may be used without embedding the actual font files, but Prawn still needs the metrics in order to lay out text on the page with the same understanding of the font metrics as a PDF reader will use.

The license in MustRead.html alongside the AFM files permits redistribution as long as modifications are noted and MustRead.html is included. Thus I believe we are in compliance with the licensing terms as that file is shipped alongside the AFM files with every distribution of Prawn.

Brad

@strzibny
Copy link
Member Author

Thank you for such a quick response! There are also .ttf fonts I am not sure about:

Activa.ttf- ?
Chalkboard.ttf - ?
comicsans.ttf - Copyright (c) 1995 Microsoft Corporation. All rights reserved.
DejaVuSans.ttf - this one is clear, public domain
Dustismo_Roman.ttf - free software
gkai00mp.ttf - (c) Copyright 1994-1999, Arphic Technology Co., Ltd.

What about them?

@bradediger
Copy link
Member

I'm not sure about those TTF files. We should definitely investigate. I'm reopening this ticket to keep track of that. Thanks.

@bradediger bradediger reopened this Apr 17, 2013
@strzibny
Copy link
Member Author

I tried to find out how Prawn really uses these fonts and it seems to me that you can just load the font without giving user-specific or system path to the font file and it's always available after installing Prawn:

Prawn::Document.generate("hello.pdf") do
  font "Courier"
  text "hello"
end

Unlike bundled .ttf for which I am getting errors:

Prawn::Errors::UnknownFont: Chalkboard is not a known font.

or

Errno::ENOENT: No such file or directory - Chalkboard.ttf

I do not believe that users would put there the path from data/ (like #{Prawn::BASEDIR}/data/fonts/comicsans.ttf) when it's not working the same as for .afm. (There is Prawn::Font::AFM::BUILT_INS but nothing like that for Prawn::Font::TTF)

And if there are not so easily accessible for users, why to pack them alongside the library? Especially if some of them can cause legal troubles? For instance we definitely have to exclude comicsans.ttf in Fedora so it would be also inconsistent for Fedora users if they shall expect it for some reason.

I noticed that 2 bundled .ttf fonts replaced original .afm fonts [1]. As I understand there might have been troubles with them, I don't think you can just exchange them for .ttf and counting on the same license agreement. Also bundling something like font files that should be system-wide available and shared among all applications is a bad practice.

Given that I suggest to abandon .ttf files from Prawn completely (at least from the distributed .gem file) or to introduce a sub-package with those files for those who wish to have them. But then again, they should not come with the copyright issues -- you could choose free alternatives, preferably under OFL [2].

If I am missing something (like their place in Prawn), please correct me and explain.

Thank you.

[1] 4c26cbc
[2] http://www.unifont.org/go_for_ofl/

@bradediger
Copy link
Member

Yes, I think you are correct that we can do away with these fonts. You are also correct that the AFM fonts are available on any PDF (compatible readers must support those 14 fonts), and the TTF fonts are used only for testing and demonstration.

I agree with you that these files should be removed; the only step remaining is to actually remove them and determine what the impact will be on our testing process. (For example, there is at least one CJKV font that is used for testing internationalized text, and we will need to vet its license or find a replacement).

Thank you!

@strzibny
Copy link
Member Author

strzibny commented May 7, 2013

@bradediger The nicest thing would be to make Prawn free from all the font files and rewrite/delete the Prawn::Font::AFM::BUILT_INS as well. That way will Prawn stay clean and slim and wouldn't interfere with system and user-installed fonts. It's always better not to bundle anything that should be shared across ecosystem.

If you prefer for Prawn to have some fonts (like build-ins afm) I really suggest a separate package that we at Fedora don't have to package. This way anybody can package Prawn for any operating system without changing it from the upstream.

If you need any/welcome any help with this or you would like to see a pull request, I don't mind looking into it, but I just want to make sure that the proposed changes are acceptable.

Thank you.

@bradediger
Copy link
Member

I agree that we need to do something about the TTF fonts that we are currently packaging. But there is no need (or indeed desire) to eliminate the "standard 14" AFM fonts. Those fonts are the standard provided by any PDF reader without the need for embedding, and there is no interference with system or user fonts. They are quite essential to Prawn and probably to any nontrivial PDF-generation program, and furthermore I don't see any licensing issues with distributing their AFM metrics, as referenced upthread. Note that the AFM files are not actually fonts (the readers have the font software itself), but rather metrics for describing the size of glyphs so that Prawn can lay out text on the page.

We will address the TTF / DFont issue (yes -- a pull request would be quite helpful on this!), but I still do not think there are any problems with our use and distribution of those AFM files.

Thanks,
Brad

@yob
Copy link
Member

yob commented May 7, 2013

I agree with @bradediger - distributing the TTF fonts is probably an artifact of the early days of the project and needing example fonts+code. We can probably find a way to get rid of them safely.

The AFM metrics are key though and must be kept. On linux system the same data is probably available from another package, but relying on that is too system specific for a pure ruby gem.

@strzibny
Copy link
Member Author

Thank you both for your clarification. On Fedora .afm is also not considered a true font file so the guideline regarding the fonts doesn't have to be applied, although seeing a general solution/approach would be nice.

For now I think I will go with packaging Prawn including .afm and excluding .ttf, if thats okay with you. I can do a pull request that deletes the fonts - but maybe if you want to keep them for testing - just excluding them from final .gem (from gemspec) so they won't appear in current final version.

What do you think?

@bradediger
Copy link
Member

That would be a great interim solution, I think. The AFM metrics are key to Prawn's operation, but the TTFs are only used for testing and generating the manual.

Thank you!
Brad

@strzibny
Copy link
Member Author

Thanks guys, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants