How about it? Anyone good with typography lengths? Could be nice to be able to convert and deal with em, px, pt… etc. Just checking to see if there is anyone enthusiastic about typography. Writing one of those supplemental units package for Unitful.jl is relatively easy.
Anyone?
i don’t disagree, however for something more than just scaling px and pt and inches and cm, i’d recommend to read the recent Font-size: An Unexpectedly Complex CSS Property - In Pursuit of Laziness which gives some insight into ‘em’ domain.
How do you display your typography?
Well, that escalated quickly… Yea, I see, so this might be impossible unless there was some kind of pt context to calculate the em in. Difficult.
Good question. I mean, there are many many outputs, none of which are natively juliaian… I personally either output straight into a tex (and then, yea, I could let latex figure it all out), or markdown and then pandoc it out to whatever.
Well actually with FreeType, Cairo and some additional code you could go to all standard outputs (ps/pdf/svg/png). I thinking now for some time to do something on top of FreeType to access all font metrics (for something more special than pango only) but looking at the time i spend on this …
So picking up from above, yes we could have some TypographicDimensions.jl but this will be way bigger than fixed scaling only.
I was about to post about this exact same thing (i.e., the problem of mixing stuff like pt and cm with em and ex, for example). I could really use this as well, and my thinking was that this could/should be handled symbolically, as an irreducable sum of two (or more) separate things. So that 1cm + 1em was just that – and you could, for example, convert that directly to (say) TeX, which could then handle the em based on the context.
However, it seems this goes beyond the current capabilites of Unitful.jl (reasonably enough). Is it a kind of (general) mechanism that could be part of such a package, or ought it involve something else entirely (such as a full-blown symbolic computation package), or something in-between, such as a custom type representing such a sum?
Or … I guess one could define em and ex (and the like) as FixedUnits (preventing conversion, but also preventing addition with other lengths), and then just use vectors or something. Or one could define a length type with one general length field, one em field, one ex field, etc., and then define addition on them. (Seems to cry out for a simpler, more general solution, though…)
(The font metrics etc. are not really of that much interest to me at present – though it may be useful. I remember actually implementing something similar based on real font metrics in Python a couple of decades ago, but that’s more work than it’s worth for my current use, where I’ll just be shipping stuff to TeX, anyway.)
1 Like
I put together a quick sketch of how this might work, here:
https://gist.github.com/mlhetland/562220c73d2b5c454c678c5df52a6540
Beyond the obvious stuff (mirroring many of the kinds of methods defined for, say, Complex), one could also have functions for specifying a conversion from em, ex and px to the absolute scale, and then resolve the sums, yielding a single, absolute length. (Or maybe go in the other direction, ending up in one of the relative dimensions, which could then later be used with other fonts/sizes.)
2 Likes
Unless someone knowledgeable objects, I don’t see why this should not be a package…? I kind of like the idea that connecting the EM, EX, and PX lengths to the rest can be handled optionally by some other external add-on package (using Require or some similar mechanism).
By publishing this now, you can let someone else pick it up when they need to and other to use this if it suffices. Cool work!
Sure thing 
I’ve polished it a bit, but am trying to improve the typing a bit (to reduce the jit-lag for computing all kinds of type parameter combinations, etc.). And I’ve run into a snag – which I wonder if may be a bug in Unitful, perhaps. It seems you can’t promote more than three unitful quantities?
For example, the following works just fine:
julia> promote(1cm, 1.0kg, 1s)
(1.0 cm, 1.0 kg, 1.0 s)
The following, however, does not:
julia> promote(1cm, 1.0kg, 1s, 1N)
ERROR: MethodError: Cannot `convert` an object of type Tuple{Unitful.Quantity{…}} …
Thoughts? Maybe it’s just a matter of defining a conversion method for tuples of quantities, to make the built-in promotion machinery work? (Haven’t studied the issue in detail.)
(oops! meant should not, got confused with the double negation: I mean this should be a package )
1 Like
No idea, you could post an issue on Unitful.
Okay, I polished the code a bit, and worked around a couple of things I had some trouble with in Unitful, and have something that seems to work okay:
https://github.com/mlhetland/UnitfulTypo.jl
The initial compile times are kind of high; I guess there might be ways to improve that. (And maybe there is some better architecture, where one could add new length-like dimensions to the mix without having to modify MixedLength.)
Anyway, I think it should be sort of usable – at least for my purposes
2 Likes
Cool!
Very cool package. The name seems a bit unfortunate since it sounds (to me) like there’s a typo somewhere and I wouldn’t guess that it has anything to do with typography. Given that the explanation is:
Typographic units for
Unitful.jl.
perhaps a good name would be TypographicUnits?
1 Like
I think it needs to have Unitful* in it, in accordance to all the other Unitful packages. So maybe UnitfulTypographics (with the plural)?
Seems like a highly breakable rule 
2 Likes
I don’t have any strong naming preferences, really. Just modeled it on UnitfulAstro.jl (and the typo thing subsequently struck me as funny ;-), but I’d be happy to change it.
Yea, I like the pun, and I guess it’s useful to know which units packages belong to which. But hey, what ever works