>> The job of a word processor is to produce a document that looks exactly like what you type on the screen. SILE takes what you type and considers it instructions for producing a document that looks as good as possible.
>> SILE doesn’t show you where the lines will break, because it doesn’t know yet.
Genuinely asking: Why cannot the above be done in real-time as the user types? (I understand that would blur the line between a typesetting system and a word processor, but if output of the typesetting system could be produced in real-time, then that boundary should not need to exist.)
I'm not sure about SILE, but for TeX, the algorithm determining the line breaks was exponential in the length of the document. Even on a modern machine, a moderately complex document will take a few seconds to run; in the 80s and 90s, my professors told me it'd take minutes to run a TeX pass.
The reason why Google Docs / Word / etc. can show the line breaks in real time is that it uses a faster (but less "optimal") algorithm.
Great, this is the type of answer I was looking for. Can you supply or point to more details please? E.g. what is the optimal line-breaks algorithm used for Tex, and what and how much is the negative impact of the less optimal one? Thanks
You can type directly into layouts in InDesign and see your line and page breaks in realtime. I think where the problem lies in InDesign is that it is, at its core, a typesetting and layout application and not a word processing application. There is a lot of work to do to get to the point of being able to write in your layout, and pages don't get added dynamically when adding new content as easily as they do in a typesetting application.
> pages don't get added dynamically when adding new content as easily as they do in a typesetting application.
InDesign will actually do this. I think it's called "Dynamic Flow" or something? It can automatically append new pages to fit the content.
In general, it's not very eager to do this because when you consider spreads (distinct left-hand and right-hand pages), inserting a new page will affect the layout of all subsequent pages. You could insert a new spread, but that may not be what the user wants.
In other words, if the user is laying out pages, actual pages matter. They aren't just an implementation detail derived from the length of the text.
You wouldn't necessarily be "writing in your layout". You could do something where you have a separate preview pane that updates in real time. Similar to what Apple showed earlier this year with their Swift playground IDE, only for typesetting.
> Why cannot the above be done in real-time as the user types?
But why would you want to do that? The display of text that is good for editing is not necessarily the same as the display of text that is good on the page.
I take that. Now we need to get to the next step to resolve that 'necessarily'. Where are the respective maximas and what specifically are the differences. PS: Answer to the above may already be well-known and obvious, so I am just genuinely asking since I do not understand it as yet, being inexperienced in this area.
I foresee mashing a robust typesetting application and a robust word processing application as being an extremely difficult thing to do well. Both are very different use cases and resulting environments.
A detailed understanding of this difficulty is what I am seeking. Can you explain more about why such a combined thing would be difficult and/or would be unable to satisfy both use cases? Thanks.
Each use case—typesetting and word-processing—have enough standardized tools to fill an entire application's interface. I think making the compromises needed to do be able to do both adequately would be too much to make either task worthwhile. Maybe that wouldn't necessarily be true for digital, like ePub, but I think that would quickly become true for print.
I don't feel a typesetting interface/context is amenable to writing long-form documents. When I take into consideration multi-column layouts, running headers and footers, art wrapping, page flow across multiple pages, there are what appears to be a lot of potential distractors from the writing process. Word processing documents, when I hide as much of the interface as I can, allow for the tight focus needed for long-form writing. Someone else in this thread suggested having writing and editing happen in another window, but that's still creating an abstraction from the layout, and not really having edits happen "in real time" if only because then editing is not happening actually within the layout.
Finally, I think there would be a significant barrier to training for many authors trying to work in layouts. There are applications, like QuarkXpress, that enable word-processing-like tools in the layout. But I couldn't imagine asking an author to learn enough about the above to ask them to write a long-form paper, much less an entire book, in that environment. Fonts are handled differently, styles are handled differently, etc.
The last time I checked, the implementation was still half-baked. Hyperlinks for example were not handled in real-time, nor were the equations if I recall correctly.
>> SILE doesn’t show you where the lines will break, because it doesn’t know yet.
Genuinely asking: Why cannot the above be done in real-time as the user types? (I understand that would blur the line between a typesetting system and a word processor, but if output of the typesetting system could be produced in real-time, then that boundary should not need to exist.)