Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error compiling. Error : Invalid magic number. #3

Open
moebiussurfing opened this issue Dec 9, 2023 · 1 comment
Open

error compiling. Error : Invalid magic number. #3

moebiussurfing opened this issue Dec 9, 2023 · 1 comment

Comments

@moebiussurfing
Copy link

Hey @tcoppex ,
Do you still use this addon?

I am getting this error at \ofxFontSampler\libs\fontsampler\ttf_reader.cc:

it seems that detect some error in the ttf files...

  /* Check that the file is correct */
  if ( (header_.filetype != 0x74727565)
    && (header_.filetype != 0x00010000)) {
    fprintf(stderr, "Error : Invalid magic number.\n");
    fclose(fd);
    return false;
  }

There's a new OF example that could be a replacement to your addon, but I suspect that it could be more performant or better to use your addon. maybe? I mean bc you have used some third-party libs...
https://github.com/openframeworks/openFrameworks/tree/master/examples/3d/pathsToMeshesExample

I have seen also this alternative:
https://github.com/moebiussurfing/ofxFontThreeDee

@tcoppex
Copy link
Owner

tcoppex commented Oct 22, 2024

Hey @moebiussurfing, sorry for the delay.

From what I can see, it looks like ofxFontThreeDee or the ofx demo has a different focus compared to ofxFontSampler, which centers more on sampling glyphs to manipulate / recreate their individual mesh rather than applying 3D extrusion on a string or glyph.

I mean bc you have used some third-party libs

Just to clarify, there’s no third-party library involved except for the ofxTriangleMesh addon used by the demo, libfontsampler is self-contained and doesn’t rely on other libraries so you might extend it as needed or create bindings for other frameworks.

Regarding the issue you might be correct. The library was initially restricted to handling type 4 CMAP TTF files, but there could be some missing edge cases. Do you still have access to the problematic TTF file? It would help to investigate further.

Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants