search

processing / p5.js

p5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. http://twitter.com/p5xjs —
http://p5js.org/
GNU Lesser General Public License v2.1
21.46k stars 3.29k forks source link

Integrate OpenType into built library? #781

Closed kadamwhite closed 9 years ago

kadamwhite commented 9 years ago

@dhowe Back in May we looked at issues relating to AMDClean and OpenType that required us to concatenate the files vs including opentype directly. I'd like to understand better how we're using OpenType within p5, so that (in our new, post-#776 browserify world) we can return to this issue and better integrate the two if appropriate.

dhowe commented 9 years ago

So we're using opentype.js to load and parse .ttf and .otf fonts, and to access metrics and path/curve data for these (and someday perhaps for font-generation) . The intention of the temporary pre-#776 grunt fix was to avoid needing a 2nd "src" tag in the browser html (only p5js, not p5js and opentype). If we want to continue in this direction, it should, I think, be relatively simple with browserify.

kadamwhite commented 9 years ago

@dhowe Would you be able to take a look at this, or talk me through where we use opentype so that I could take a swing at it?

We could also conceivably switch to declaring opentype.js as an NPM dependency, rather than maintaining the externals directory, as we do with reqwest.

dhowe commented 9 years ago

Well, we use the library throughout the typography module (src/typography/* and src/io/files.js ). But an NPM dependency makes sense to me (the externals dir was part of that quick-fix and not meant to be permanent), especially if we're already doing that for reqwest. I believe this was where we ran into trouble integrating with AMD due to clashing symbols. Anyhow, on NPM: https://www.npmjs.com/package/opentype.js.

kadamwhite commented 9 years ago

This may be blocking #818 since it means we end up with two UMD definitions in one file. I'm putting together a PR to require opentype into the constructed bundle. This would mean opentype would no longer be a global, however, so it could only be used by an end user via p5's interface (loadFont etc)—this seems fine to me, but I thought I'd raise it just in case.

dhowe commented 9 years ago

I'm assuming you mean any exposed functions in the library (for example, we now expose p5.Font.textBounds(), which is not actually part of the official p5 API (or p5's direct interface). If so, then this seems fine to me as well.

kadamwhite commented 9 years ago

I think we're discussing the same thing, but as I'm less familiar with the font module I'm not 100%. Do you have some tests that you could do or recommend I do to verify things are copacetic?

dhowe commented 9 years ago

Maybe a bit of a larger task, but something I've done in the past is to check access to the entire API as part of a test set; so there might be a JSON file with a list of objects and the functions/variables/constants they expose, and the test can simply check each is defined and has the correct type (you might also test that private elements are not visible). The idea being that you can do devops-type refactoring more safely, but it can also be useful for documentation (we may already have something like this for use in the web reference...)

either way, in the meantime, I'll add some specific tests for the p5.Font case