Error parsing some cut font files using 'opentype. parse(...)'

[hanke677]

**Firstly, I only know a little English. I hope you can understand it. Thank you again!!

I have some font files with unknown sources, but I have a rough understanding that they should have been cut, leaving only some text used in the files. But I don't know how they cut this file. Some font files couldn't be opened by double clicking with the mouse, and I tried to parse them using opentype. parse (...) from opentype.js. Not surprisingly, different errors will be reported. But to my knowledge, there are some font parsing libraries that can be opened (possibly belonging to the backend). I really need to parse these font files correctly without using only opentype.js, because these cut fonts cannot be directly introduced into the browser. I need to obtain the missing character codes to depict the corresponding text to complete my task.

So, if anyone knows how to solve this problem, or can modify the source code of opentype.js from the perspective of error reporting, please let me know or provide me with relevant guidance. I am very worried that opentype.js will not be able to solve my problem, and I really need your reply!

Here are some screenshots examples of errors and problematic font files:**



fonts.zip

Looking forward to your reply！！

[Connum]

Seems to me as if these files are broken beyond recognition. I doubt that they will be read by any other implementation. Nevertheless I might have a look at them if I find the time.

[hanke677]

Seems to me as if these files are broken beyond recognition. I doubt that they will be read by any other implementation. Nevertheless I might have a look at them if I find the time.
Thank you and look forward to your reply！！！

[Connum]

Fontforge is able to open those files, if that helps you.
We'll have to restructure error handling in opentype.js in the future, to be able to open fonts with errors instead of throwing errors early and implement font.validate()in a more useful way (see #607).

[hanke677]

Fontforge is able to open those files, if that helps you. We'll have to restructure error handling in opentype.js in the future, to be able to open fonts with errors instead of throwing errors early and implement font.validate()in a more useful way (see #607).

Thank you again. I will study 'Fontforge', but I want to directly handle these font files in web projects, and using 'Fontforge' requires some additional configuration and compilation, which I am not very good at. Additionally, its volume may be too large, which may have some impact on the performance of my project. So, I still look forward to you and other members making the refactored opentype.js available in the near future!

[Connum]

What I can say so far is that font_13_13.otf is that it is an old Adobe Type 1 (PostScript) font. Even Adobe itself as dropped support for those in their own products. This is out of scope for this library which is targeted towards OpenType fonts (hence the name). Let's see whether we can treat incomplete fonts like the other two more gracefully in the future.

[Connum]

You can check out this work-in-progress branch for a more forgiving handling of incomplete font files:
https://github.com/Connum/opentype.js/tree/WIP/validation-error-handling

[hanke677]

I tested the new branch you gave me and solved most of the challenges in nearly a hundred classic cases. This is really great! But there are still two issues before I can complete my arduous task with opentype.js. One issue is that there may still be an error during testing, which may be caused by incomplete font files. Below, I will provide you with an example. Another issue is that the Type1 font you mentioned earlier cannot be supported, as some of my old users still use this font, so they need to be parsed. So here, I have a few more questions to ask you:

1. The new branch you provided me can already solve most of the problems, but it may not be enough. Do you think there is still room for optimization and reconstruction in error handling, and are there any special situations that have not been taken into account; Also, are you planning to merge this restructured branch into the main branch? If not, please guide me on how to incorporate it into my web project.

2. Do you and your team have any plans to support Type1 fonts in the future, as I need support for this font. I don't seem to be able to find any other good font solution that is entirely JavaScript except for opentype.js, and I can't directly use other plugins written in C in my web project, which will result in huge performance waste.

Finally, I hope that opentype.js can become the only font solution suitable for the web end!!! Thank you again for your reply!!!

font_14.zip

[Connum]

There are probably too many cases of what can go wrong with a font, but with each example provided we can address more places in the code that prevent incomplete fonts from loading. I'll check that file as well, but probably won't have the time for it today.

Once I finish working on the error handling, I'll make a draft PR to see what other contributors think of the approach. Then I'll have to rework some comments in the code that still reference the throwing of errors where we no longer actually throw them, update the README for the new handling and add tests. So this will surely take a while.

You can either run the build and dist scripts and use the dist files in your project, or you can install the branch as a git dependency:
npm install "https://github.com/Connum/opentype.js.git#WIP/validation-error-handling"

Regarding the Type 1 fonts: I frankly doubt that this is worth the work, seeing how old they are and that they are largely not supported today. This library is for loading opentype fonts. I understand it would be nice to be able to use it for converting old fonts, but I would argue that it's not really in scope.

May I ask what your project is about that you have so much old or incomplete font data?

[Connum]

font_14 seems to be a raw CFF table, but I'm not entirely sure yet. While fontforge manages to open even that, I'm not sure if opentype.js should really support that... I think I would prefer to open up the parsing process to make it extensible via a plugin system.

[hanke677]

font_14 seems to be a raw CFF table, but I'm not entirely sure yet. While fontforge manages to open even that, I'm not sure if opentype.js should really support that... I think I would prefer to open up the parsing process to make it extensible via a plugin system.

I think your analysis is correct and can even be understood as a font file with a suffix of cff. Okay, so far there are only two issues that need to be addressed: support for cff and type1 file types, if this is in your future plans. Even choosing to extend other plugins for support is a good choice. As long as it can solve the problem, it is the most crucial help for me, and it is also a good supplement for opentype.js.

Finally, I look forward to your good news!!!

[Connum]

With the latest update to the branch, CFF Type1 will load. It might not be complete, but should be enough to get the glyph paths and some basic meta data. As we already support parsing of CFF Format 1 as a part of OpenType fonts, this one was easier to implement than the PostScript fonts.

[Connum]

So I hacked together a solution for loading the PostScript Type1 fonts, here's a proof of concept:

However this is not viable as a solution to be integrated into opentypejs itself, because it depends on another library and as I said, this format is so old that Adobe itself will no longer support it. It will have to be made into a plugin, but we'll need to implement a plugin system first. This shouldn't be done in one step and will take some time.

[hanke677]

However this is not viable as a solution to be integrated into opentypejs itself, because it depends on another library and as I said, this format is so old that Adobe itself will no longer support it. It will have to be made into a plugin, but we'll need to implement a plugin system first. This shouldn't be done in one step and will take some time.

That looks so great, I can't wait to use the new version anymore. So far, it seems to have solved all my problems. If there are new similar problems in the future, I think I will still propose to help opentype.js expand it.

[hanke677]

May I ask if the support for type1 font parsing is still in your and your team's development plan? ~

[Connum]

May I ask if the support for type1 font parsing is still in your and your team's development plan? ~

Sure, it's just that not much development happened over the holidays. We should merge in some of the outstanding PRs before I'll prepare a plug in solution.

[Connum]

@hanke677 may I ask why you're closing this? I already put in some work to implement this, and although it will probably be a plug in solution instead of being added to the core, I would like to keep track of it here, because we'll also need to implement a few changes to the core in order to be able to provide a plugin.

[hanke677]

i reopened this if you need to track it

[hanke677]

@hanke677 may I ask why you're closing this? I already put in some work to implement this, and although it will probably be a plug in solution instead of being added to the core, I would like to keep track of it here, because we'll also need to implement a few changes to the core in order to be able to provide a plugin.

It occurred to me that I might not have enough license to display the contents of this font file directly in the issue, so if you can, I think you should remove the picture information from the history chat and keep following it

[Connum]

Showing pictures of a font is no issue

[hanke677]

Long time no see, I'm back again! I used your development branch in my project, combined with the toSVG() method, and they performed very well! After testing a large number of incomplete fonts, although the CFF font was able to parse successfully, I was unable to find the corresponding text using the given index code. It seems that I lost the index code of the font, and the type1 font still cannot parse successfully, but currently the other test fonts perform perfectly. I have a high level of interest in your pull request, so I would like to ask if there are any new developments on this issue? I am willing to provide relevant tests if they are useful.

[hanke677]