Pages 3.0: Poor handling of space character at very end of line
Posted by Pierre Igot in: PagesDecember 6th, 2007 • 10:43 am
Depending on the font face and size setting that you are using, Pages’ text rendering engine can suffer from some rather problematic behaviours. Here is one that I encountered this morning.
I had a paragraph of left-aligned text in Times New Roman size 11 pt in a Pages document and I was typing text near the end of a line in the paragraph:
It just so happened that the last word that I had just typed (“site”) was almost perfectly aligned with the edge of the right margin, as can be seen in the picture above.
So then I just hit the Space bar once to insert a space and was about to type the next word when I noticed something strange:
Pages had indeed inserted the space, but for some reason the blinking “I-beam” cursor was still located right after the final “e” of “site.” Not notincing that the space was there and thinking I had just not hit the Space bar properly, I hit it again. And again. And again. Nothing seemed to happen. What was going on here?
That’s when I realized that there was indeed a single space (the pale blue dot) after the final “e” of “site,” but that for some reason Pages was drawing the “I-beam” cursor at the wrong place.
And indeed if I continued typing more text, Pages continued on the next line and everything appeared to be fine.
But then I went back to this situation that I had just encountered and tried to explore it more closely. And here’s what I saw. This is the situation when the I-beam cursor is just after the “e” of “site,” without a trailing space:
And here’s exactly what I get after pressing Space once in this situation:
Pages has inserted a space, but the I-beam cursor is still right after the “e” of “site.” Yet it behaves as if it were after the space, i.e. if I press Delete then, Pages deletes the trailing space and leaves the I-beam cursor in the same spot, which is now its actual location.
Even more strange, if I press the Space key repeatedly in order to insert several space characters, Pages does seem to insert them, but only in some invisible, off-screen domain. The multiple spaces do not appear either at the end of this line or at the beginning of the next. But they are registered somewhere, because I then press the Delete key, I have to press it multiple times, i.e. the exact same number of times I have pressed the Space key, in order to delete all these invisible space characters.
It is very weird. You should be able to reproduce this yourself with the following Pages document:
TrailingSpaceProblem.pages.zip
Just open this document, place your insertion point (I-beam cursor) at the very end, right after the “e” of “site,” and try to type one or more space characters. You should be able to see what I see.
Needless to say, I am submitting this as a bug report via Bug Reporter right away.
December 6th, 2007 at Dec 06, 07 | 11:23 am
Interesting. I’ve seen this kind of thing in Pages in justified text, and I supposed then that the dynamic justification simply ignored the trailing space. There’s not excuse for this in left-justified text.
December 6th, 2007 at Dec 06, 07 | 11:42 am
I am not using Pages but the problem still sounds pretty familiar to me. You can even reproduce it in TextEdit or Safari’s textareas (like this comment field), so I’d guess it’s a general problem of the Cocoa text system in some way.
December 6th, 2007 at Dec 06, 07 | 1:40 pm
Yes, I too suspect that it’s a symptom of a deeper problem. Whether Apple considers it an important problem to fix, of course, remains to be seen.
December 6th, 2007 at Dec 06, 07 | 5:12 pm
This also happens with OpenOffice (all platforms) and WordPerfect (at least 6.1-12), (though OpenOffice, when showing nonprinting characters, doesn’t draw the space).
This seems like a deliberate making-the-best-of-a-bad-situation choice to me, rather than a bug. It wouldn’t make sense to put a blinking cursor in the margin, and when you’re not showing nonprintable characters, there’s nothing visually wrong with the placement.
I thought it happened in Word too, but I just tried it on WinWord 2003 and it doesn’t happen there. Instead, the blinking cursor does extend into the margin. (If you press space repeatedly at the end of a line, the cursor extends all the way to the edge of the page — then disappears off the edge.)
December 6th, 2007 at Dec 06, 07 | 6:07 pm
Yes, another reader pointed out to me that there might be something intentional about this… If you start typing multiple space in the middle of a line and then continue until you reach the right-hand side, instead of wrapping around to the beginning of the next line, Pages continues horizontally in an “invisible” portion of the document. In Word 2004 too, as in WinWord 2003, the cursor continues in the margin, which is even weirder.
The “intentional” aspect might be that this meant to prevent people from using multiple spaces to force an automatic line break. I am a bit doubtful that people might actually want to do this in the first place, but I suppose there are all kinds of really weird behaviours out there…
The bottom-line, though, is that Apple could avoid the situation described in my blog post by just moving the blinking I-beam properly for that one trailing space, even if it encroaches on the right margin a bit. It could still block the automatic wrapping and refuse to continue on the next line, but it should still at least move the I-beam cursor to the right of the one space character that is still visible at the end of the line. Otherwise, it looks really weird.
I agree that there is probably no easy solution to the bigger problem of what to do when people try to type multiple spaces at the end of a line, but that little minor adjustment would make things less confusing for people who only type a single space at the end of the line and expect the cursor to behave the same as with any other space anywhere else in the paragraph.
There is, after all, no immediate visual sense that one has reached the margin and that this particular space extends beyond the left border of the right margin. Indeed, the drawing of the blue dot when showing invisibles shows that Pages is perfectly capable of drawing the space char, even though it extends beyond the left border of the right margin. So if it can draw the space, it should be able to draw the I-beam cursor in the right location too, even if strictly speaking the I-beam cursor “shouldn’t be there” (in the margin).
December 6th, 2007 at Dec 06, 07 | 10:26 pm
I believe this is not a new problem. If I remember correctly, the same thing happened in ClarisWorks 2.0 (which I was using on an old SE/30 running System 7.1). However, I agree with Pierre that it is an annoying problem. The blinking I-beam should move to the right of the trailing space. I am now used to it, but the best thing that could happen regarding this is if Apple fixed it.
December 7th, 2007 at Dec 07, 07 | 1:51 pm
It’s not clear to me how you’d fix this. Moving the caret into the margin after the first visible space might make sense, but what about people who insert two spaces after the end of a sentence? That approach would still be confusing for them. Also, if you’d allow the caret to move into the margin, you’d also have to allow text selections (highlighting) to move into the margin, otherwise there would be a disconnect between selections and the location of the caret. I can see advantages in both the current approach and the Microsoft Word approach, but I’m not sure the halfway approach somewhere in between would really satisfy anyone, and it would probably increase code complexity in the text system.
December 7th, 2007 at Dec 07, 07 | 2:11 pm
Well, if it really were up to me, I would eliminate the “feature” altogether and just make spaces behave like any characters, i.e. wrap around to the beginning of the next line. If people are dumb enough to use spaces as a substitute for line breaks, it’s their problem, really… There are already so many ways that people can misuse word processors with multiple tabs and spaces for alignment purposes. One additional form of abuse won’t change much.
That said, it wouldn’t solve the problem completely, because obviously you’d need to avoid having spaces at the beginning of a line, and, particularly in the case of justified text, you’d still have to let trailing spaces “hang” in the right margin. But support for hanging punctuation already exists in an application such as InDesign, and when it comes to highlighting the selection InDesign is not shy about altering the shape of the highlighting to include the punctuation that is “hanging” in the margin:
December 8th, 2007 at Dec 08, 07 | 10:17 am
I would *love* InDesign’s text handling (including margin typography/microtypography) to be included in OS X’s text system. The only system that compares to InDesign is LaTeX with the microtype extensions (not surprisingly the same Ph.D. who developed those is the one who went to Adobe and worked on the InDesign text system). But from a programming standpoint it adds a lot of complexity. I took a look at InDesign’s extension API a few years ago and the text stuff is really very complicated. Of course that may be an argument for getting it integrated into the Cocoa text system :)