Error parsing some cut font files using 'opentype. parse(...)' about opentype.js HOT 21 OPEN

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.

from opentype.js.

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！！！

from opentype.js.

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).

from opentype.js.

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!

from opentype.js.

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.

from opentype.js.

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

from opentype.js.

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

from opentype.js.

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?

from opentype.js.

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.

from opentype.js.

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!!!

from opentype.js.

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.

from opentype.js.

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.

from opentype.js.

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.

from opentype.js.

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

from opentype.js.

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.

from opentype.js.

@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.

from opentype.js.

i reopened this if you need to track it

from opentype.js.

@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

from opentype.js.

Showing pictures of a font is no issue

from opentype.js.

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.

from opentype.js.

from opentype.js.