TrueType and OpenType fonts already have embedding bits and
tables/fields for including licence, trademark, copyright, designers
url, etc. in the font file. Trouble is the fonts embedded in PDF files -
especially if they were originally TT or OT - are *not* the same as the
original font file. Most or all of this information, which may have been
in the original font file, is probably no longer there in the PDF
embedded font.
Fonts in PDF files are essentially like the fonts in a document sent to
to a PostScript printer. (BTW with a terminal emulator, serial
communications with the printer, and a few simple commands you can also
"extract" fonts from a PostScript printer). Unicode fonts may get split
into a number of smaller fonts and all OpenType tables etc. are gone.
- Chris
Gustavo Ferreira wrote:
Op Nov 12, 2008, om 12:18 AM heeft George Williams het volgende
geschreven:
On Tue, 2008-11-11 at 11:21, Gustavo Ferreira wrote:
does fontforge do any kind of checking before importing a font from a
pdf?
No, because there is generally no such information available. In
fact it
isn't clear to me that any font format contains this information --
until FontLab's EEULA table gets fleshed out.
do you mean that there is no bit related to the particular situation
of importing a font from a pdf?
or that the bits are not readable from a font contained inside a pdf?
regarding the eeula table -- i think i remember you suggesting once
that it is possible to add any new tables to an (opentype? truetype?)
font. (sorry, i don't remember the context of that discussion.)
what would be necessary to have an eeula table implemented in fontforge?
do you have any remarks in relation to the proposal presented on the
eeulaa.org website?
would it be reasonable to ask that the "open font from pdf" function
imports only fonts with the proper permissions, and fails to do so
when it is not permitted by the font?
:-) If you know how to do this, feel free.
hmm. this is c code?
if you can do it, i can make you some nice icons... ;-)
cheers,
- gustavo.
