Clojurians Log v2
membrane
Does membrane have facilites for nuanced typographic rendering? Looking for things like: • font weight • italic variants • letter spacing • font stretch (vertical / horizontal) • line height • baseline shift • subcaps I’m assuming this depends on the runtime (backend) implementation. This stuff i think is table stakes in css. But I’m looking towards a java/clj implementation to keep it all in process and maybe enable more data composition and direct manipulation/animated workflow? Probably to render to an image for inclusion in web design. Any thoughts? Embed css-styled html inside a java/membrane canvas?
> But I’m looking towards a java/clj implementation to keep it all in process and maybe enable more data composition and direct manipulation/animated workflow? Probably to render to an image for inclusion in web design. Any thoughts? Embed css-styled html inside a java/membrane canvas?
There's a couple options.
• If you render with skia using membrane.skia.paragraph, you can draw directly to an image with membrane.skia/save-image. This is probably the best option.
• Java2d does have some stuff for rendering formatted text. It's been a while since I've looked at it. I remember the rendering not looking as good, but it might depend on the styles and fonts. You can also render that directly to an image.
• Skia also has an SVG view, membrane.skia/svg. I think that should work with CSS, but haven't tried.
There are other more complicated setups depending on your needs.
Yeah I remember java2d and even java-fx having some suboptimal font rendering and aliasing issues.. Might check it out again. But i assume skia has the best graphical primitives. SVG, interesting, did think of that for typography but it actually makes more sense of designy api.
What is the state of general typographic layout? (paragraphs, text flow, etc?). I know this is a deep rabbit hole..
You can see https://phronmophobic.github.io/membrane/styled-text/index.html which should cover most use cases. This implementation is skia only, but my hope is to create a standard API with a few small changes that can be implemented by all of the backends.
Yes, those names come from skia, https://github.com/google/skia/blob/f8ec973447335269111891765446b1695b5acd22/include/core/SkFontStyle.h#L32. Skia is the graphics library that chrome uses to render their UI and all of the HTML.
Nice 🔥I think that covers everything but font-stretch. I will try it out!
what is font-stretch?
Not sure if this is a native font feature. But something I use a lot in photoshop.
oh, it looks like it's actually supported, but not documented
Actually, I think it is documented. I think font-stretch is actually the same as setting the :font-style/width.
> Note: The font-stretch property https://drafts.csswg.org/css-fonts/#font-stretch-desc`font-width` in the specifications.
At least if you're talking about the same option as the css font-stretch property. That's one of the benefits of using skia is that you should theoretically be able to render anything that you find in the browser.
Yes. I thought at first the :condensed, etc parameters were referring to letter spacing.
But indeed in css parlance, it refers to stretching the glyphs!
I was thinking more about stretching arbitrary percentages. And that is supported by css, and also seems require a compatible typeface.
I’m confused by the reference to css names. Are those names you are mirroring in your api? > Skia doesn’t have built-in properties like font-stretch or font-width, but you can achieve similar effects programmatically: > • Use setScaleX for horizontal scaling (wider or narrower text).
I’ve also been exposing more and more of the layout information which will be part of the next release.
I’m away from keyboard, but I’ll be back in a bit.
The API is still open to feedback. One thing I'll probably change for the standardized APIs is to use fewer namespaced keywords. I find them to be cumbersome in the membrane.skia.paragraph API without much benefit.
I’m sympathetic to this.
While I’m more appreciative of clojure’s focus on data provenance in the large (vs type systems). I find namespaced keywords add lot of noise to local logic and can make it less fun to read and reason about code.
Yup. I'll probably update the API to also allow unqualified keywords at some point. I do try really hard to maintain backwards compatibility so I'll probably spend a bit more time thinking about the how to grow the API in a way that improves usability and maintains backwards compatibility.