Font selection for text layers

[0HyperCube]

Closes #504
Closes #529
Closes #508

• Fetch fonts and put them into dropdown in the properties panel
• TextArea to add to text properties
• Download selected font and render.

[cloudflare-pages]

Deploying with    Cloudflare Pages

Latest commit:	9dbde20
Status:	✅  Deploy successful!
Preview URL:	https://4b905e63.graphite-master.pages.dev

View logs

[Keavon]

Glad to see this coming along, nice work! Just some quick comments while I notice them (you're probably already aware of these, but here are some nice checkboxes to serve as reminders):

• We'll want the tool's options bar to have the font selection also
• And that means renaming the font size from "Font" to "Size"
• And in the Properties panel, we also want a Size field
  Excited to see this come along!

[Keavon]

This works great!

• How feasible would it be to remove the built-in font now? This would reduce our wasm build size by a couple megabytes. But I realize that means it has nothing to default to when you first start typing. Although I suppose that's no different than first picking a different font before you start typing. So that's probably the best tradeoff?
• Can we have a "Style" dropdown to pick the different weights/italics/other variants? (Both in the options bar and properties panel.)

[0HyperCube]

• How feasible would it be to remove the built-in font now? This would reduce our wasm build size by a couple megabytes. But I realize that means it has nothing to default to when you first start typing. Although I suppose that's no different than first picking a different font before you start typing. So that's probably the best tradeoff?

I have removed the font (although it was only one style and was ~200kB) and instead load it when the editor is initialised (so we don't hang if the user goes offline and then types text for the first time).

• Can we have a "Style" dropdown to pick the different weights/italics/other variants? (Both in the options bar and properties panel.)

Done

[Keavon]

• It would be great if we can apply the (specific variant of the) font to the editing mode (foreign element in the SVG).
• The term "Style" not "Variant" is more standard.

We should talk about how to make the CtrlB and CtrlI shortcuts work to switch into/out of bold and italic styles. We'll need some way to detect a weight (like figuring out where "regular" fits into the numbered weights which is usually 400 but doesn't have to be) and italics/oblique-or-not value and then intelligently pick sane default weights for bolded and non-bolded. Mixing font weights/styles in the same line of text will get even more interesting. Not in scope for this PR though.

This branch is reminding me that I definitely also need to prioritize some work on improving the Properties panel's horizontal scrolling and layout flexbox behavior to prevent horizontal scrollbars and the mess they cause with floating menus. That'll also improve with the fix you made in #583 once merged. For now, the user can make it usable by just widening the Properties/Layer panels column.

I built a Cloudflare Workers worker to proxy the Google Fonts API (with some caching), so you don't have to include your API key in the final build. It's using one I created for Graphite now, so you can go ahead and deactivate your testing API key (which is now visible on the public internet forever).

[Keavon]

I'm also noticing that it takes a bit of time (maybe ~1/3 of a second) to display a populated FontInput widget, during which time the UI hangs. This happens when switching to the Text tool (so the options bar displays it) or selecting a text layer (so the Properties panel displays it). I assume this is time spent serializing and deserializing in the process of sending the data from the backend to the frontend. I wonder if there's any way we can change the architecture so that data lives readily available on the frontend, or it gets streamed to the widget on scroll, or it gets loaded asynchronously in order to not hang the main UI thread.

[0HyperCube]

This branch is reminding me that I definitely also need to prioritize some work on improving the Properties panel's horizontal scrolling and layout flexbox behavior to prevent horizontal scrollbars and the mess they cause with floating menus. That'll also improve with the fix you made in #583 once merged. For now, the user can make it usable by just widening the Properties/Layer panels column.

I also can't seem to get the height for the textarea to be more than one row without breaking the css @Keavon.

[0HyperCube]

I'm also noticing that it takes a bit of time (maybe ~1/3 of a second) to display a populated FontInput widget, during which time the UI hangs. This happens when switching to the Text tool (so the options bar displays it) or selecting a text layer (so the Properties panel displays it). I assume this is time spent serializing and deserializing in the process of sending the data from the backend to the frontend. I wonder if there's any way we can change the architecture so that data lives readily available on the frontend, or it gets streamed to the widget on scroll, or it gets loaded asynchronously in order to not hang the main UI thread.

@Keavon The fonts and variants list is kept in js in a local variable inside fonts.ts. The rust only sends and receives strings for the variant, the font name and the file path. I would assume the slowness comes from adding ~8400 dom nodes but I'm not really sure how to profile it or what to do about it.

[0HyperCube]

We should talk about how to make the CtrlB and CtrlI shortcuts work to switch into/out of bold and italic styles. We'll need some way to detect a weight (like figuring out where "regular" fits into the numbered weights which is usually 400 but doesn't have to be) and italics/oblique-or-not value and then intelligently pick sane default weights for bolded and non-bolded. Mixing font weights/styles in the same line of text will get even more interesting. Not in scope for this PR though.

In the font list, the regular variant is always called regular and italic always ends in italic with regular italic just being italic. CSS always maps bold to 700 and normal to 400 so I don't think we should complicate it further as long as we don't stop the user from choosing any variant. We can fake italic by applying a skew as well as faking bold if the variant does not exist. Mixed styles is just a case of loading a new font and laying out the text span in that font but starting from the last position, although we also need to handle if there are fonts with different line heights on the same line. The mixed styles can be stored as Vec<{span_content: String, font: String}>. Making this work with content editable whilst you are typing would be challenging though.

[Keavon]

I also can't seem to get the height for the textarea to be more than one row without breaking the css

I was working earlier on improving that by making TextAreaInput reuse FieldInput (which I extended to use both <input> and <textarea>), with CSS to handle proper visual display. However I broke the event handler functionality and didn't have time to debug it. I can push that if you'd be willing to help find the cause of the event handling no longer working. (Edit: I pushed it.)

The fonts and variants list is kept in js in a local variable inside fonts.ts. The rust only sends and receives strings for the variant, the font name and the file path. I would assume the slowness comes from adding ~8400 dom nodes but I'm not really sure how to profile it or what to do about it.

Indeed, I profiled this just now and it looks like it is mostly a bunch of Vue functions running. That'll be something to improve in the future. I also would love the FontInput widget to display previews of the fonts someday, although that would require a lot of loading. To reduce the loading, we'd make it load only the ones visible at the moment, and we can use that same idea to only populate the DOM elements for the ones visible.

In the font list, the regular variant is always called regular and italic always ends in italic with regular italic just being italic. CSS always maps bold to 700 and normal to 400 so I don't think we should complicate it further as long as we don't stop the user from choosing any variant. We can fake italic by applying a skew as well as faking bold if the variant does not exist. Mixed styles is just a case of loading a new font and laying out the text span in that font but starting from the last position, although we also need to handle if there are fonts with different line heights on the same line. The mixed styles can be stored as Vec<{span_content: String, font: String}>. Making this work with content editable whilst you are typing would be challenging though.

It looks like you are right about this, it's more standardized than I realized. (Very thin fonts on Google Fonts, like this one, which only have one style should maybe be weight 100 in reality, but it still lists it as 400/regular.) So the code should be pretty simple. Replace "regular" with "400" and "italic" with "400italic", then find the ones ending in `"italic", and use 400 for regular and 700 for bold. CtrlB switches the current weight to 700 if currently lower than 700 or to 400 if current at or above 700. CtrlI switches from the non-italics version to the italics version of the closest weight to the current weight.

• We might also want to clean up the ugly API names that show up in the dropdown menu by matching them to the closest name in this list, perhaps with the numerical weight in parenthesis, like: Regular (400) or Extra Bold (800) or Extra Bold (825), the last example being in the event of a weird weight that matches to the closest name but shows the exact number).

[Keavon]

For this and all these other functions related to transformation, it seems pretty inappropriate to have to pass the font cache here. Can the cache instead live as a reference on struct Layer? Presumably that means lifetimes may get tricky, or perhaps that's even illogical to make Graphene handle that. Maybe give a copy of the data to Graphene? I'm not really sure what the best solution is here. @TrueDoctor perhaps you have any thoughts?

[0HyperCube]

@Keavon Don't think so (unless we use something from std::sync), as we need to get mutable access to the font cache (i.e. dropping all other references) when we load a new font.

[Keavon]

I'm so pumped for this feature, it's really, really awesome.