Bug 1669905 Comment 6 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

> the "virtual pages" are supposed to represent miniature shrunken-down versions of the same paper size that's being printed onto

Ah, interesting. I haven't seen your new pages-per-sheet feature in action yet, so I didn't know that's how it worked.  I agree that choosing an optimal scaling/placement automatically makes sense for this scaled-down page model.

> The version shown in your dialog looks a bit more similar to a version of CSS Multicol where the virtual columns are simply space-filling. 

Yes, these are different models indeed. The layout-preserving scaled-down pages approach makes sense for media that is inherently page-oriented, like PDF/PS etc.   The divide-the-page-into-columns model is more interesting for fluid layouts that can adapt to different viewport sizes, like plain text, or indeed, web content.  I remember from my distant university days that we printed source code using this model to maximize the number of lines you could print on a sheet (double-sided 2-column landscape mode was the best for legible text IIRC).  There are likely many other use cases for this as well, for example if you have a long list of names that would normally just use the left side of the sheet, which would be more optimal using 3 or more columns in landscape mode.  Just scaling things down is in many cases sub-optimal since it makes the text illegible pretty quickly.

But you're quite right that what I was thinking about is more like a page column layout - having more than one row per sheet doesn't really make sense in this model.

BTW, the example on the right in your screenshot has wrong orientation?  I would expect it to be rotated 180deg so that the start of the page is on the left and text flowing down to the right (at least for `writing-mode:horizontal-tb`).  Anyway, I think it makes more sense choose to the choose one on the left and leave the other one for Landscape mode.  I think if we place pages in a (physical) top-left to bottom-right sequence in both Portrait/Landscape then it should cover all useful layouts.

BTW, I tested 2-pages-per-sheet (with A4 size) in Chrome and it doesn't seem to preserve the sheet aspect ratio at all. The resulting sheet looks more square to me even after printing it to a PDF (I didn't check how it would end up on a printer though, maybe it's scaled down again to fit the physical sheet size?).  Weird... maybe just a bug?
> the "virtual pages" are supposed to represent miniature shrunken-down versions of the same paper size that's being printed onto

Ah, interesting. I haven't seen your new pages-per-sheet feature in action yet, so I didn't know that's how it worked.  I agree that choosing an optimal scaling/placement automatically makes sense for this scaled-down page model.

> The version shown in your dialog looks a bit more similar to a version of CSS Multicol where the virtual columns are simply space-filling. 

Yes, these are different models indeed. The layout-preserving scaled-down pages approach makes sense for media that is inherently page-oriented, like PDF/PS etc.   The divide-the-page-into-columns model is more interesting for fluid layouts that can adapt to different viewport sizes, like plain text, or indeed, web content.  I remember from my distant university days that we printed source code using this model to maximize the number of lines you could print on a sheet (double-sided 2-column landscape mode was the best for legible text IIRC).  There are likely many other use cases for this as well, for example if you have a long list of names that would normally just use the left side of the sheet, which would be more optimal using 3 or more columns in landscape mode.  Just scaling things down is in many cases sub-optimal since it makes the text illegible pretty quickly.

But you're quite right that what I was thinking about is more like a page column layout - having more than one row per sheet doesn't really make sense in this model.

BTW, the example on the right in your screenshot has wrong orientation?  I would expect it to be rotated 180deg so that the start of the page is on the left and text flowing down to the right (at least for `writing-mode:horizontal-tb`).  Anyway, I think it makes more sense to choose one on the left and leave the other one for Landscape mode.  I think if we place pages in a (physical) top-left to bottom-right sequence in both Portrait/Landscape then it should cover all useful layouts.

BTW, I tested 2-pages-per-sheet (with A4 size) in Chrome and it doesn't seem to preserve the sheet aspect ratio at all. The resulting sheet looks more square to me even after printing it to a PDF (I didn't check how it would end up on a printer though, maybe it's scaled down again to fit the physical sheet size?).  Weird... maybe just a bug?
> the "virtual pages" are supposed to represent miniature shrunken-down versions of the same paper size that's being printed onto

Ah, interesting. I haven't seen your new pages-per-sheet feature in action yet, so I didn't know that's how it worked.  I agree that choosing an optimal scaling/placement automatically makes sense for this scaled-down page model.

> The version shown in your dialog looks a bit more similar to a version of CSS Multicol where the virtual columns are simply space-filling. 

Yes, these are different models indeed. The layout-preserving scaled-down pages approach makes sense for media that is inherently page-oriented, like PDF/PS etc.   The divide-the-page-into-columns model is more interesting for fluid layouts that can adapt to different viewport sizes, like plain text, or indeed, web content.  I remember from my distant university days that we printed source code using this model to maximize the number of lines you could print on a sheet (double-sided 2-column landscape mode was the best for legible text IIRC).  There are likely many other use cases for this as well, for example if you have a long list of names that would normally just use the left side of the sheet, which would be more optimal using 3 or more columns in landscape mode.  Just scaling things down is in many cases sub-optimal since it makes the text illegible pretty quickly.

But you're quite right that what I was thinking about is more like a page column layout - having more than one row per sheet doesn't really make sense in this model.

BTW, the example on the right in your screenshot has wrong orientation?  I would expect it to be rotated 180deg so that the start of the page is on the left and text flowing down to the right (at least for `writing-mode:horizontal-tb`).  Anyway, I think it makes more sense to choose the layout on the left and leave the other one for Landscape mode.  I think if we place pages in a (physical) top-left to bottom-right sequence in both Portrait/Landscape then it should cover all useful layouts.

BTW, I tested 2-pages-per-sheet (with A4 size) in Chrome and it doesn't seem to preserve the sheet aspect ratio at all. The resulting sheet looks more square to me even after printing it to a PDF (I didn't check how it would end up on a printer though, maybe it's scaled down again to fit the physical sheet size?).  Weird... maybe just a bug?
> the "virtual pages" are supposed to represent miniature shrunken-down versions of the same paper size that's being printed onto

Ah, interesting. I haven't seen your new pages-per-sheet feature in action yet, so I didn't know that's how it worked.  I agree that choosing an optimal scaling/placement automatically makes sense for this scaled-down page model.

> The version shown in your dialog looks a bit more similar to a version of CSS Multicol where the virtual columns are simply space-filling. 

Yes, these are different models indeed. The layout-preserving scaled-down pages approach makes sense for media that is inherently page-oriented, like PDF/PS etc.   The divide-the-page-into-columns model is more interesting for fluid layouts that can adapt to different viewport sizes, like plain text, or indeed, web content.  I remember from my distant university days that we printed source code using this model to maximize the number of lines you could print on a sheet (double-sided 2-column landscape mode was the best for legible text IIRC).  There are likely many other use cases for this as well, for example if you have a long list of names that would normally just use the left side of the sheet, which would be more optimal using 3 or more columns in landscape mode.  Just scaling things down is in many cases sub-optimal since it makes the text illegible pretty quickly.

But you're quite right that what I was thinking about is more like a page column layout - having more than one row per sheet doesn't really make sense in this model.

BTW, the example on the right in your screenshot has wrong orientation?  I would expect it to be rotated 180deg so that the start of the page is on the left and text flowing down to the right (at least for `writing-mode:horizontal-tb`).  Anyway, I think it makes more sense to choose the layout on the left and leave the other one for Landscape mode.  I think if we place pages in a (physical) top-left to bottom-right sequence in both Portrait/Landscape then it should cover all useful layouts.

EDIT: deleted the comment about Chrome not preserving the sheet ratio, I think I was just confused how it looked in Okular which had automatically zoomed it to fit the window...

Back to Bug 1669905 Comment 6