Hello,
I'm hoping to get some insight on how one can mimic the behavior of center text alignment as in that of text applications. I need this to happen at the font level, within specified contexts. Effectively, the centering rules need to apply after a target character (let's say, "G" as in the image below); the text following would position appropriately, below and centered.
I can manage to position the bottom portion...that part's easy. It's the centering of these characters (as a unit) that is proving quite the challenge. Sure, centering one character is fairly simple: calculate the number of characters above and target the bottom portion at the mid point, apply an offset if necessary and it's done. But what happens when we're dealing with more than one character to center, and at that, how does one compensate for the varying character widths overall, for the top and/or bottom portion?
Is this achievable within Open type rules?
Many thanks for reading.
Comments
In limited cases, it's possible (you would bin the glyphs into groups by their advance width and use a very large set of contextual rules to "count" the number of characters on each line - I do something very similar in this plugin), but tell me more about what you're trying to achieve and why and we'll see whether it's worth it.
Thank you kindly for your replies.
My apologies, I should have clarified:
I'm not trying to invoke a line break. The text I'm entering is on the same line. i.e. Both words would be part of a single string of characters (no carriage returns or the like). Further to this (not shown above), both words would be separated by an underline separator which would also need centering. So, in effect, I'm trying to vertically align and center three items from a single input string; top text, underline, bottom text.
I already have rules subbing in all of the above and placing them in the required vertical positions, calculating the number of lines (underscores) for the underline width, etc. It's the horizontal centering of this data (in unison and in relation to each other) that's the challenge.
I hope this explanation is clearer.
Thanks again.
So, supposing (for simplicity) all default glyphs have an advance of 100 FUs, substitutions would replace
[C.dflt E.dflt N.dflt ... T.dflt E.dflt ...]
with
[C.dflt E.200 N.300 ... T.dflt E.200 X.300 T.400]
(After the "wrap" trigger, you'd start over, or you could even end those subs, though that might not be worth it.)
Then, on the second line, you could do subs that start at the end accumulating the widths back to the beginning of that segment. (This is why subs in the above pass aren't relevant for the second segment.) So, you'd end up with something like
[G.900.trigger T.400 E.300 X.200 T.400]
Then you could do a positioning adjustment that has the trigger glyph variant, with accumulated width from the first line, as context, adjusting the width and position of the first glyph on the second line, with amounts determined by the variants of the trigger glyph and the first glyph that each reflect the total width of the respective segments (in this case, +250 pos x and +250 advance].
Would I want to do this? Only as an experiment to see if what I outlined is actually feasible.
I have a sense of what you're saying. I'll have to reread it a few times as I'm still learning the Open Type ropes as it were. Although, I get the sense that there are several ways to do what I need, your approach being one of them. Just guessing, of course.
Very much appreciate your reply!
In the end, I made a few pre-composed glyphs for simple fractions, and left the rest to the normal diagonal-virgule method.
I'm working on a method that's sort of what some of you suggested but shouldn't take too many rules to construct. In the end, it may only work in one direction. i.e. Centering may only happen on the bottom portion; the top portion would remain aligned left...it'll sort of work but I'm still working it out in my head
Thank you all for your thoughts and suggestions.
Pair adjustments are always top of mind. With what I've got going so far, none of the usual glyph adjustments are affected.
The result I'm going for won't be perfect; I'm well aware that it would take a ton of code to get that going 100% correctly in a font. I'd settle for 85-90% accuracy, which is just about where I'm at now.
As for additional glyphs, I'm not adding any whatsoever.
1. Single substitution of a real glyph ID with a virtual glyph ID that represents that glyph plus some extra info. A different virtual glyph ID would be used for each real glyph ID.
2. Multiple substitution of a real glyph ID with a sequence of that same glyph ID plus a virtual glyph ID, the latter representing only the additional information. The same virtual glyph ID could be used for multiple real glyph IDs when the same additional information is to be indicated.
If by virtual glyph ID, you simply mean writing rules to call up (sub to/from) the original glyphs, then I get it. Beyond that...I've got much to learn with all this lingo!
In a nutshell, I've got multiple subs happening; one on the first glyph of the input string (applying an underscore and first character), and another multiple at the trigger glyph (inserting multiple underscores...offset...), then I'm able to input the bottom characters with another offset. The rest...centering, is still problematic; and as most of you have concluded, it'll require an insane amount of rules to tame.
O.T. Anyone know what Open Type resources I should read up on, online classes and the sort?
Thanks to everyone once again.
I would love to be wrong about this, because it is a powerful tool for some fancy operations. I would also be curious to hear what toolchains people envision for getting such lookups into fonts. (And ideally, also how they would interact with using more friendly tools for any "normal" features.)