Doris Chen writes to the Framers mailing list, << Your comments only touched upon another series of typographic problems which revolves around the handling of the space character in Frame. There are six situations in which the space character should never be allowed: At the start of a paragraph At the end of a paragraph Before a tab stop After a tab stop Before a hard return After a hard return All of these items stand in the way of precision type setting. If you think the anomylies that you discussed concerning the edge of a text column are bad you should see what these situations do to the type setting of tables. If any of the preceeding situations occur in a table it is impossible to get columns of data to line up even when you are using fixed width fonts. As a minimum the smart spaces option should prevent you from ever creating any of the preceeding situations. Further the extra spaces optionn of the spell checker should report and correct any of these situations which occur. Another related problem is allowing typographic font changes (font, size, bold, etc.) for blocks of text which contain only spaces. As a document ages, a problem occurs as a result of subsequent editting. Say you had some text that was originally bold. You later deleted or made unbold the text, but did not include all the spaces in the font change. (Most common occurrance is leading or trailing blanks). You now have a bold blank between two words in normal font. The typesetting algorythms in Frame treat the bold blank as having a differrent width (as they should). The results can be really strange and difficult for a user to detect on the screen. The solution is for Frame at least at open and save time to change spaces which do not have the typographic attributes of their surrounding text set to match the surrounding text. This should not be done to much more often then open or save since it is a very compute intensive task. The problem is so severe we had to write an API program to go through documents and clean out these problems before final printing. ------------------------------------------------------------------------------- For more information contact: Doris Chen Softline International, Inc. voice (510) 849-9817 fax (510) 849-0156 email doris@softline.com ------------------------------------------------------------------------------- >> (A copy of this message has also been posted to the following newsgroups: comp.text.frame) In the Framers note forwarded by me , Doris Chen wrote, > There are six situations in which the space character should never be allowed: [numbers mine] > 1 At the start of a paragraph > 2 At the end of a paragraph > 3 Before a tab stop > 4 After a tab stop > 5 Before a hard return > 6 After a hard return > > All of these items stand in the way of precision type setting. I agree that Frame suffers from all of these problems. Since version 1.05 on the Mac, eight years ago (!), Microsoft Word has not suffered from problems 2 or 5. These spaces are allowed in a document, but they properly make no contribution to linebreaks or wordspacing of the line. You could argue that cases 2 and 5 should not be permitted, but here's an argument in favor of Word's treatment: it makes sense to treat the space following a word as an entity to be edited along with the word. In the English language a word is frequently followed by a space! Consider moving a word or two from one place to another in a document, surely a common occurrence. I double-click to select a word (perhaps I then drag to select a few more), then cut, then place the insertion point somewhere else, then paste. I probably want the space character to come along with the word. This is precisely what happends in Word. And it extends beautifully into drag'n'drop editing: double-click (maybe drag), let go (see the selection), mouse-down on it, then drag'n'drop it. The spaces work out as a function of the design of the interaction. In Frame, there's no drag'n'drop. But in the select-cut-click-paste scenario, with smart spaces off, two spaces are left at the source and none are provided at the destination. With so-called "smart spaces", the two spaces at the source close up into one, but no space is provided at the destination: the inserted word butts up against the word at the point of insertion. What I've described is what I consider to be a class-I human-interface bug in the "smart spaces" logic. In Frame 3.1 this all worked fine, as in Word, but it was broken upon the release of 4.0 and remains broken in 5.0, despite my continued pleas to tech support. I wrote and submitted a one-pager on this more than a year ago, and followed up with two or three phone calls. But no one that I spoke with at Frame considered this to be misbehavior on the part of Frame, despite the behavior being demonstrably different from 3.1 to 4.0. This relates to spaces before paragraph marks and spaces before hard returns: if sentences are to be treated as entities during editing, they too should be permitted to be followed by spaces, without interfering with layout of lines or table cells. I ought to be enabled to drag across a sentence (complete with period and following space), cut, click and paste -- and produce an intact paragraph, without having to manually trim the spaces. In Word, I can easily do what I want. In Frame, if a space immediately precedes a paragraph mark, the line layout (or table cell layout) algorithm breaks. Word follows a typewriter model, so in cases 1, 2, 4 and 6 it makes sense for Word to act on the space. Otherwise the Word users would get too confused. I concur with your view that in FrameMaker these should be suppressed. I would argue to leave one of them in the document, but have it occupy zero-width, like a marker does today: simply have the layout machinery ignore them, as it should ignore the spaces in cases 2 and 5 above. > Another related problem is allowing typographic font changes (font, size, bold, > etc.) for blocks of text which contain only spaces. I too have been burned by this one. C. Charles Poynton [Mac Eudora, MIME, BinHqx] tel: 416 486 3271 fax: 416 486 3657