On Jul 6, 2004, at 3:53 PM, Aaron Sherber wrote:

>There are a lot of things we routinely did in
>typesetting that aren't done now.  A few things aren't even possible.
>Most are possible in the better programs but rarely are.

I'd be interested in hearing more about this, possibly off-list. I feel like Quark is about as close to manipulating actual type as you can get.

It's been a few years since I've used Quark, so I'm probably a little out of date. Quark was definitely the most typeset-like of the DTP programs, but it still wasn't the same.


The specific feature I most miss from my typesetting days is auto-tabs. In brief, you can add a code anywhere in your text which says "start/stop tab here". The when the type is calculated, whatever position turns up for that spot in the text it becomes the value for the tab definition. If you like, I can offer some examples in a follow-up post, but I assure you that they're immensely useful, and I've never encountered anything like them in Quark or any other DTP application.

Tab definitions in general are often screwy in DTP. I don't recall how they work in Quark, but in Word they're clumsy. In typesetting every tab definition has an ID, a left margin, a width, and a justification parameter (ie, justified, flush left, flush right, or centered). Probably it's just out of habit, but to me that feels like the essential information, no more and no less. Other applications which I've used have tab definitions which manage to simultaneously be more complicated and less specific. In some apps (I forget which) as soon as you have a line break, you're out of the tab, unless you had a hanging indent to go with it, which to me seems stupid, though again that's probably just force of habit. Others might think it's stupid that you *don't* leave the tab.

Another typesetting code I miss is "insert space". The <is> code goes along with things like flush left and justification. It means, "whatever extra space there is in this line, put all of it here". So if you've got one bit of information to be flush left and another bit to be flush right on the same page, you can just put an <is> between them, instead of having to make separate tabs. Also you can have several insert spaces in the same line and it'll split the space proportionally. Combining auto-tabs with insert-space is the best way to make a table; it's much harder to do well in DTP.

I also miss basic codes that move forward, backward, up and down. In the old days, before kerning tables were very good, we used to use backward and forward codes for kerning. Even when automatic kerning is working fine, they're still useful for other things. And I miss being able to move the baseline around without breaking up the logical line.

The common theme for all of this is wysiwyg, which changed everything. In typesetting, you are essentially writing high-level code, in which each normal character is a simple command meaning render that character under the current parameters and all the rest are various functions to manipulate those parameters. So when you define a location where the text is going to appear, you actually define it by offering coordinates. DTP programs are designed around the idea of point-and-click and drag things into place. The actual code is under there somewhere, but you're removed from it. Quark was the most typeset-like because it was the most advanced in offering dialog boxes to let you manipulate parameters directly, but it was still based on a scheme where the wysiwyg was the interface. Typesetting, on the other hand, did develop wysiwyg displays, but you still did your actual editing in the code, with the display as a sort of on-the-fly rendering. Some of the early DTP programs approximated this with their "display code" modes but that didn't really take off.

This is why tabs are different and line spacing is different, because the traditional coding doesn't lend itself to graphic interface as well. In typesetting, your line space distance is a parameter that you set just like font or size. Any time a return character comes along, whether soft or hard, the baseline moves down by whatever the current line space value is. But in wysiwyg there's no real sense of "current". Selecting some text and changing the font or size is intuitive, but changing the life-space is less so. Consequently, the DTP programs try to second-guess this for you based on the sizes of type within the line. The better programs provide ways to override this and specify line-spacing exactly, but it's less natural and thus most users don't do it. That's why you see so much text with crappy line-spacing choices nowadays. The user is trained to think that it's something he shouldn't worry about, as if the leading for 10-pt type ought to be the same whether the column width is 12 picas or 33.

As I noted, the better DTP programs give you ways to do this. As in Finale, just about anything is possible if you're willing to find the right tool to make it happen, but some things come more naturally than others, and some things are more roundabout than they used to be. The best typographers still know what looks good and they'll find a way to make it work, but most users don't know and don't care.

I could go on and on about this, but I'm sure that's plenty.

mdl

P.S. Lest I give the wrong impression, I should note that I don't hate everything about DTP. For example, it's nice to be able to define a paragraph indent and not have to put in your own em-space. I absolutely love style definitions, though some apps implement them better than others. That's something that was only just getting started in typeset when DTP came along and rendered it all obsolete. Styles are wonderful. I'm definitely not opposed to all progress. On the other hand, if a DTP program came along where the basic paradigm was that you edit the code and the wysiwyg display is just a display, I'd definitely prefer that.

_______________________________________________
Finale mailing list
[EMAIL PROTECTED]
http://lists.shsu.edu/mailman/listinfo/finale

Reply via email to