search

silnrsi / font-ttf-scripts

Font::TTF::Scripts perl module
Artistic License 2.0
19 stars 7 forks source link

fret: "undefined value" on reading *.otf #19

Closed wollmers closed 5 years ago

wollmers commented 6 years ago

Maybe I missed something in the docs, but fret throws an error on *.otf files:

$ fret LOV.WieynckKursiv.otf
Can't call method "read" on an undefined value at /Users/helmut/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/Font/Fret.pm line 187.
mhosken commented 6 years ago

Fret only works with TrueType outlines and a glyf table in the font.

GB, Martin

On Wed, 18 Apr 2018, 13:37 Helmut Wollmersdorfer, notifications@github.com wrote:

Maybe I missed something in the docs, but fret throws an error on *.otf files:

$ fret LOV.WieynckKursiv.otf Can't call method "read" on an undefined value at /Users/helmut/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/Font/Fret.pm line 187.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/silnrsi/font-ttf-scripts/issues/19, or mute the thread https://github.com/notifications/unsubscribe-auth/AFbHbZGUoRP1ACTIt4oS5uT7YG6Go_roks5tpt85gaJpZM4TZf3r .

wollmers commented 6 years ago

@mhosken Thanks for the reply.

After reading the specs of OpenType, TTF/AAT and Adobe, and also investigating a dozen OSS packages, I have a better understanding of the problem.

Comparing the most promising alternatives (Adobe Type Tools Font-API, Python fonttools, Font::TTF) to build on, I decided to start with Font::TTF and modify it into Font::OTF.

Roughly estimated 30-70% of Font::TTF is reusable to some degree to support .otf. It's well structured and readable.

Additional question: Is there a preferred or most popular XML-format for font data, which should be supported?

mhosken commented 6 years ago

Dear Helmut,

I recommend fonttools with the ttx tool if you want to go the XML route.

GB, Martin

On Thu, 19 Apr 2018, 15:47 Helmut Wollmersdorfer, notifications@github.com wrote:

@mhosken https://github.com/mhosken Thanks for the reply.

After reading the specs of OpenType, TTF/AAT and Adobe, and also investigating a dozen OSS packages, I have a better understanding of the problem.

Comparing the most promising alternatives (Adobe Type Tools Font-API, Python fonttools, Font::TTF) to build on, I decided to start with Font::TTF and modify it into Font::OTF.

Roughly estimated 30-70% of Font::TTF is reusable to some degree to support .otf. It's well structured and readable.

Additional question: Is there a preferred or most popular XML-format for font data, which should be supported?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/silnrsi/font-ttf-scripts/issues/19#issuecomment-382659121, or mute the thread https://github.com/notifications/unsubscribe-auth/AFbHbXgUtoZPlDoZ0sz9-BptbSrjAYN2ks5tqE81gaJpZM4TZf3r .

wollmers commented 6 years ago

Dear Martin,

personally I prefer Perl structures in my application of OCR and OFR (Optical Font Recognition). Serializing a Perl structure to JSON is just one line of code. Nearly all popular script languages like Python, PHP, JS can handle JSON nicely, and developers like it.

In my experience dealing with different XML formats e. g. for the results (the page segmentation, bounding boxes) of OCR systems, XML can be boring.

Supporting XML is more a matter of integration with other tools. Popular ones seem to be tx and ttx.

For OFR alone I can also use bitmaps of the glyphs, i. e. render them, or use scans of old type specimen catalogs. That's the way I do it now. But dealing with the guts of fonts directly opens new opportunities. One is creating fonts (of poor quality) from scans automatically.