This one is plain tricky. Let’s say you want to create a compact format for handling blocks of text on a page. Basically, what you have is a horizontal position, and a vertical position. To simplify matters, we’ll just envision the height as a percentage of the total height of the page (trick number one). As for horizontal positioning, we just need the alignment (left, center, or right), because the regular page width doesn’t really allow for several blocks (trick number two). Since it’s used mainly for subtitling, it’s enough.
In these days of old, it was normal (still is, by the way, but so uncool) to have the origin of your page in the top-left corner. The positioning worked like that :
You might think this is kind of obvious, right? And most of the time, it works! If you want to fine-tune your horizontal positioning, you use… spaces. Yeah, I know, but it works, right?What happens when you have several lines? You have to make sure that your text still fits within the page, and then calculate the height of the block so that it sits on the bottom line, and has the right height :
Then comes the new generation of software that can edit this kind of blocks. The developers see this somewhat simplistic way of thinking about blocks, and think “hell, thinking from top-left, when we have a base line that doesn’t move is stupid. We’ll just say that the block has to be high enough to accommodate all the text, and then build from the bottom”:
That’s just forgetting that all the blocks are not sitting on the base line! “No problem, you just pad with new lines!” is the answer. So, as of today, we have a format that has only one vertical position that you adjust with returns, and 3 horizontal positions that you adjust with spaces. How clever is that?
The only problem is that the documentaion stops at the first generation. And this “clever” and “intuitive” design is just, well, not.