invalid otf creation? (FIXED)

[tastez]

hi just wondering if the OTF created on the Brutalita editor is supposed to be a valid OTF or its for a specific usecase - i can't seem to open it in windowz or import it on the web. Is it only to be used with the opentype library only?

[javierbyte]

hello! @tastez, it should work as is, at least it is working for me on mac os, I can install it and use without modifying it. Also I was able to convert it to woff2 to use it here https://javier.xyz/pintr/

I haven't tested on windows so probably there is a bug to fix, could you please run one of the OpenType.js examples https://github.com/opentypejs/opentype.js/tree/master/examples and see if they produce a valid OTF font for you? It would help me know if this is a bug of OpenTypejs itself (that I might be able to fix by converting the font before exporting) or if it a bug in the way in which I'm using OpenType.js

Thank you!

[jch02140]

Hi,

I am also having trouble with the downloaded Brutalita OTF file from the website not being a valid font file in Windows... I ran the Opentype.js example which I am able to open the OTF file without any problem...

Also, I noticed this when highlighting the text... Not sure if it helps... You will see the highlighted text turned into another font (or most likely system default one)...

[javierbyte]

@jch02140 thank you for testing. I'm setting up a windows VM to replicate the issue.

I just pushed a change that removes some params that I was sending to OpenType.js that are not needed, it is unlikely that it will fix the issue for windows but maybe.

Also, this https://cloudconvert.com/otf-to-woff2 is the converter that I used to get the web font of for another project, maybe you could use it to convert the OTF to TTF and see if that fixes the issue for Windows for now.

The textarea visual bug that you see is unrelated to the font creation, the font that you see on the editor and the font that you download are created by different renders (one is SVG and the other is OpenType.js), I'll this information to the readme but here is a reply that I made on hacker news about the same visual glitch:

When you download the font then it is a normal font and that [the visual bug] does not happen. On the website, to make it possible to edit the characters in real time I'm drawing the font as SVG behind an invisible textarea; so when the text is edited really the textarea is changing and I'm drawing SVG behind every character to make it look like a textarea with the custom font. I'm curious which browser/OS are you using since I don't see the textarea text when I highlight something.

Seems that the invisible textarea it not completely invisible on some OS, (it is on mac for me), I pushed some style changes that hopefully will fix those issues for all OS; I'll make they work after I get my VMs setup.

[javierbyte]

@tastez @jch02140 hey! I think I fixed the error on windows, please let me know if it works :)

[jch02140]

The text highlight bug is fixed. The downloaded font still does not work in windows. I am still receiving an error that the file is not a valid font file.

However, when I try to open the font file in a font editor program like FontLab, it seems to work...

Also, I noticed some default glyphs and any custom one seems to have unknown encoding (marked with a ? in FontLab), perhaps this could be one of the reasons why Windows seems to consider it as an invalid font file?

Update: The last five glyphs, á é í ó ú (which seem to be part of the default glyphs) don't seem to actually work in the online editor even though they exist in the font file... The online editor just simply displays them in red...

[javierbyte]

@jch02140 thank you for the feedback. á é í ó ú are part of an experimental feature to combine characters, á was a + ´ combined just before building the font. I removed them from the production build just now, while I keep investigating the windows error.

[javierbyte]

Ok, so I made some changes

• Added a table with unicode names https://github.com/javierbyte/brutalita/blob/master/src/lib/named-character-references.csv so now non latin characters would get a name from the table instead of using the character itself as the name, this might have been causing some issues.
• I removed some characters that seems to be problematic on windows, see:

I noted that on windows there is some polygon overlapping issues on small font sizes, I used cloudconvert to convert from OTF to TTF to test and the issue is not present there:

I'll see if I can implement a polygon intersection algorithm to fix the issue, but there has been some progress fixing the windows issues and downloading a custom font should be working now. @jch02140

[javierbyte]

@jch02140 everything should be fixed now

[jch02140]

Just tested and the OTF file can now be open normally now. Thanks for the quick fix.

[tastez]

excellent! thank you

[javierbyte]

thank you all for testing