4 ms·

I don't understand your points here. It does seem that Google Docs is using the browser to measure and render individual units of text. But that is very much n

I don't understand your points here. It does seem that Google Docs is using the browser to measure and render individual units of text. But that is very much not the same thing as layout: deciding how much text fits onto a line, how many lines fit onto a page, making room for footnotes, etc. My understanding is that Docs is handling layout itself, in order to support features like pagination and footnotes. You say the browsers can support all of the layout features Docs provides, but do they allow live editing and on-screen display of paginated text? That certainly wasn't the case back when I wrote the original Google Docs (I'm a co-founder of Writely) and I don't believe it was the case when the current canvas implementation shipped. (I had left Google by then and have no inside knowledge of that rewrite.) One final note: back in the day, I have implemented and shipped a full word processor for the Mac (FullWrite). We very much handled layout ourselves, but relied on the OS for text measurement and rendering, presumably in a similar fashion to how Docs leverages the browser today.

barnabee 3y ago
> My understanding is that Docs is handling layout itself, in order to support features like pagination and footnotes I’ve seen the same Google Doc use different numbers of pages both on screen and in print/PDF so I don’t believe this is correct.
- snewman 3y ago
  This is not strong evidence. While, ideally, the behavior you describe should not happen, there are many reasons it could arise. (Bugs, font sizing comes out differently at printer resolution, paper size is different than on-screen page size, different implementation for printing, etc.) Given that Docs nowadays uses Canvas to render the document being edited, how would it even be possible to delegate rendering to the browser? (Not to mention the challenge of live rendering of pages, footnotes, etc.)
chrismorgan 3y ago
Text shaping is a critical part of layout. Different systems use different and incompatible techniques, e.g. in measuring slightly different things, or in using fixed-point or floating-point calculations, and a variety of other such things—quite apart from differences in capabilities (e.g. whether you support complex layout for certain languages, or certain newer Unicode features). Every serious desktop publishing system uses its own shaping engine, configured to act in a platform-independent way (some will otherwise try to match the platform’s conventions). It’s worse when you do it with browsers, because you can’t inspect anywhere near as much, and because you can’t even guarantee which font will be used: font files may fail to load (networks are far less reliable than people imagine, quite apart from third-party origins), or you might get users like me who just disable custom fonts altogether because it makes the general experience of the web so much better. As far as pagination is concerned, there was never any reason why you couldn’t do that in DOM—and in fact, Google Docs did do it in the DOM. You simply have to monitor where the break position should be, and adjust things at that point. It’s not hard. The specific adjustment, there are a few approaches for. You could have the whole document be a contenteditable, and draw the page background outside that, and just inject an inline spacer element in the location of the break; or maintain it inside distinct block elements, using text-align-last on the last line of the previous page if it’s mid-paragraph and justified (or an approximation of the effect for older browsers); or there are several other viable approaches. Seriously, it’s not hard. You’re not limited to “just contenteditable”, you expect you have to maintain various more complex DOM. But I contend that maintaining that is easier that rendering the whole thing in a canvas, and entirely adequately powerful, and probably faster, if you perform similar performance optimisations, and that it functions better. I just all-round cannot think of any legitimate reason why they went the way they did. It’s not like switching from DOM to canvas allowed them to add any new functionality: no, they stayed at just the same feature set, just worse in places, from my perspective.
- deleted 3y ago
  [deleted]

barnabee 3y ago

> My understanding is that Docs is handling layout itself, in order to support features like pagination and footnotes I’ve seen the same Google Doc use different numbers of pages both on screen and in print/PDF so I don’t believe this is correct.

snewman 3y ago
This is not strong evidence. While, ideally, the behavior you describe should not happen, there are many reasons it could arise. (Bugs, font sizing comes out differently at printer resolution, paper size is different than on-screen page size, different implementation for printing, etc.) Given that Docs nowadays uses Canvas to render the document being edited, how would it even be possible to delegate rendering to the browser? (Not to mention the challenge of live rendering of pages, footnotes, etc.)

chrismorgan 3y ago

Text shaping is a critical part of layout. Different systems use different and incompatible techniques, e.g. in measuring slightly different things, or in using fixed-point or floating-point calculations, and a variety of other such things—quite apart from differences in capabilities (e.g. whether you support complex layout for certain languages, or certain newer Unicode features). Every serious desktop publishing system uses its own shaping engine, configured to act in a platform-independent way (some will otherwise try to match the platform’s conventions). It’s worse when you do it with browsers, because you can’t inspect anywhere near as much, and because you can’t even guarantee which font will be used: font files may fail to load (networks are far less reliable than people imagine, quite apart from third-party origins), or you might get users like me who just disable custom fonts altogether because it makes the general experience of the web so much better. As far as pagination is concerned, there was never any reason why you couldn’t do that in DOM—and in fact, Google Docs did do it in the DOM. You simply have to monitor where the break position should be, and adjust things at that point. It’s not hard. The specific adjustment, there are a few approaches for. You could have the whole document be a contenteditable, and draw the page background outside that, and just inject an inline spacer element in the location of the break; or maintain it inside distinct block elements, using text-align-last on the last line of the previous page if it’s mid-paragraph and justified (or an approximation of the effect for older browsers); or there are several other viable approaches. Seriously, it’s not hard. You’re not limited to “just contenteditable”, you expect you have to maintain various more complex DOM. But I contend that maintaining that is easier that rendering the whole thing in a canvas, and entirely adequately powerful, and probably faster, if you perform similar performance optimisations, and that it functions better. I just all-round cannot think of any legitimate reason why they went the way they did. It’s not like switching from DOM to canvas allowed them to add any new functionality: no, they stayed at just the same feature set, just worse in places, from my perspective.

deleted 3y ago
[deleted]