"shrink to fit page width" wraps lines instead of shrinking to fit

ASSIGNED
Assigned to

Status

()

Core
Printing: Output
ASSIGNED
4 years ago
4 years ago

People

(Reporter: Felix Miata, Assigned: mats)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
Created attachment 8367811 [details]
plain text testcase, 100 columns by 80 rows

During today's testing with new profiles, release rv24 worked as expected, release rv25 and up did not. 

To reproduce:
1-start with virgin profile
2-select preferred monospace font size in preferences
3-open attachment
4 [review]-print using:
  a-page 1 only
  b-yes: ignore scaling and fit to page width
  c-portrait orientation
  d-default printer margins
  5-all header & footer fields set to blank

Actual results on 8.5"X11" letter paper:
1-@96DPI & 12px monospace font size: longest lines wrap; 65 lines print
2-@120DPI &12px monospace font size: longest lines wrap; 54 lines print
3-@120DPI & 18px monospace font size: longest lines wrap; 38 lines print
4-@144DPI & 22px monospace font size: longest lines wrap; 32 lines print

Expected results on 8.5"X11" letter paper:
1-no lines wrap
2-line spacing inexplicably varies (by DPI? by monospace font family? maybe another bug?), but here rv17 @96DPI/12px prints 71 rows, @120DPI 12px prints 60 rows, @120DPI/18px prints 64 rows, and @144DPI/22px prints 68 rows (66 rows was my target, normal for typewriter PICA). IOW, regardless of DPI or font size setting, line count variation is somewhat narrow, and font size variation is imperceptible, compared to actual results.

Notes:
1-18px@120 and 22px@120 were selected to approximate 11pt physical at those screen densities, similar to what 14.5px might be @96.
2-Printer drivers used (both latest known available from Canon for MF4370dn):
cndrvcups-common-2.70-1.i386 & cndrvcups-ufr2-us-2.70-1.i386
3-Unconfirmed bug 863357 might be this, but its testcase is not a Language I understand, and its attachment does not validate, making it impossible for me to tell whether it is a match or not.
4-Previously I had thought this began in a release 1-3 versions older than rv25. I had months ago locked down my most used profile to rv21 until last week because of this, and forgot about ensuring this had been reported.
(Assignee)

Comment 1

4 years ago
It appears the "mShrinkRatio" is 1.0 in the layout/printing code... so it doesn't
even try to scale it down.  I'm guessing this is because the page actually wraps
the long line so it appears to fit.  If I take your text file and put it inside
a <pre> and print that HTML document then I get mShrinkRatio=0.920968 and it
works as expected.  So it looks like we've added "word-wrap: break-word" to
plaint text documents and that's the root of the problem.  (You can verify that
by loading the attachment and then type F12 and then Inspector and clicking
on the <pre> in the tree view.)
(Assignee)

Comment 2

4 years ago
I suspect bug 253564 is the culprit.  Fwiw, I found a workaround - select
"Basic Page Style" in the "View->Page Style" menu and then print.

Still, I would expect "wrap wrong lines" to be disabled while printing
with "shrink to fit".
Blocks: 253564
Keywords: regression
OS: Linux → All
Hardware: x86 → All
Most simply, we could make that stylesheet @media screen only.
(Reporter)

Comment 4

4 years ago
(In reply to Boris Zbarsky [:bz] from comment #3)
> Most simply, we could make that stylesheet @media screen only.

No wysiwyg layout that way.
Print preview should be a sufficient wysiwyg. It might not be available on all platforms iirc though.
(Reporter)

Comment 6

4 years ago
(In reply to Jared Wein [:jaws] from comment #5)
> Print preview should be a sufficient wysiwyg. It might not be available on
> all platforms iirc though.

My experience with print preview in Geckos is that printer output rarely looks like print preview output, and 9+ sheets get wasted for every good one printed. I'm guessing that's yet another component that rarely gets tested in any DE that is not at or assuming 96 DPI screen density.
Created attachment 8368179 [details] [diff] [review]
WIP Patch

Mats, I used media="screen" here because I couldn't get media="not all and (print)" to work. Do you know why that wouldn't work?
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Attachment #8368179 - Flags: feedback?(matspal)
(Assignee)

Comment 8

4 years ago
Comment on attachment 8368179 [details] [diff] [review]
WIP Patch

(In reply to Jared Wein [:jaws] from comment #7)
> Mats, I used media="screen" here because I couldn't get media="not all and
> (print)" to work. Do you know why that wouldn't work?

I don't know, it seems like it should work.
Does wrapping the rule in layout/style/plaintext.css in @media ... { } work?

That said, I actually like the new wrapping, except for shrink-to-fit.
If we disable it for Print then we get truncated lines instead, which seems
worse (dataloss) than the reported problem.

So I'd prefer a fix in the print engine that somehow disables/overrides
the break-word wrapping only when shrink-to-fit is enabled.  Would that
be possible?  (I don't really understand how plaintext.css is loaded -
I tried dumping the sheets in the styleset for the pres context in
the print object, but that didn't contain any plaintext.css)
Attachment #8368179 - Flags: feedback?(matspal) → feedback-
(Assignee)

Comment 9

4 years ago
(In reply to Jared Wein [:jaws] from comment #7)
> Mats, I used media="screen" here because I couldn't get media="not all and
> (print)" to work. Do you know why that wouldn't work?

Actually, that media expression looks odd - isn't "not print" what you intended?
(In reply to Mats Palmgren (:mats) from comment #2)
> Still, I would expect "wrap wrong lines" to be disabled while printing
> with "shrink to fit".

I disagree, specifically because "Shrink to fit" is the default, and it shouldn't have footguns. (And no-wrap printing is a footgun that leads to illegible (or effectively blank) printouts, as in bug 960822.)

For comparison, my text editor (gedit) wraps plain-text in print-preview (though to be fair I suppose it doesn't have a 'shrink to fit' option to turn off or on), and Firefox itself wraps the text as well when rendering it on-screen. So I think it's reasonable to expect that long lines might be wrapped.

The wrapping might be annoying, in cases like the attached testcase, at least it doesn't lose data (as no-wrap does, when you print things too small to be legible), and you can work around it by explicitly picking a smaller zoom level.

(Perhaps if shrink to fit were something that folks had to actively select, then this might make sense. But as the default, I think we should keep it as dataloss-free as possible. My feeling is that Shrink-To-Fit is more for shrinking to accommodate un-wrappable content, like e.g. a large image or a div with a fixed width, since there the alternative is truncation which is a worse form of dataloss.)
(In reply to Daniel Holbert [:dholbert] from comment #10)
> The wrapping might be annoying, in cases like the attached testcase, at
> least it doesn't lose data (as no-wrap does

(sorry, I meant to say "...but at least")

Also, for the record -- my local testing (and the 'target milestone' field on bug 253564) shows that this behavior changed in Firefox 22, not 25.
(Reporter)

Comment 12

4 years ago
(In reply to Daniel Holbert [:dholbert] from comment #10)
> (In reply to Mats Palmgren (:mats) from comment #2)
> > Still, I would expect "wrap wrong lines" to be disabled while printing
> > with "shrink to fit".
 
> I disagree, specifically because "Shrink to fit" is the default

I don't see what default has to do with anything. What purpose jumps in the face of any ordinary human for shrink to fit except to prevent line wrap while not truncating long lines? I'm not familiar with any other applications that even offer shrink to fit, which is precisely why I use Gecko to do my printing of plain text files.

> I think it's reasonable to expect that long lines might be wrapped.

I think it antithetical to the entire concept.
 
> The wrapping might be annoying, in cases like the attached testcase, at

Not just annoying, but wasteful. I need what I see printed as I see it displayed on screen. Wrapping has no business disrupting this need to both get what is expected, and waste neither time nor paper nor toner.

> you can work around it by explicitly picking a smaller zoom level.

Not here you can't. Zoom level has zero perceptible impact on this Linux system on printing.
 
> (Perhaps if shrink to fit were something that folks had to actively select,
> then this might make sense. But as the default, I think we should keep it as

Why is it default?
(In reply to Felix Miata from comment #12)
> I don't see what default has to do with anything. What purpose jumps in the
> face of any ordinary human for shrink to fit except to prevent line wrap
> while not truncating long lines?
[...]
> I think it antithetical to the entire concept.

So, in my understanding, the purpose/concept of Shrink To Fit in our print UI is:

"See if there's any content that would normally trigger a horizontal scrollbar (or otherwise render out-of-bounds) when rendered to a printed page. Normally, we'd truncate this content, since we can't print a functional scrollbar or allow dynanmic browser-resizing in a printed page. So instead of truncating that content, adjust the zoom level such that it fits without needing a scrollbar."

> > The wrapping might be annoying, in cases like the attached testcase, at
> 
> Not just annoying, but wasteful. I need what I see printed as I see it
> displayed on screen.

I take it you're looking at it in a browser that's > 8 inches wide. If you shrink your browser to the width of a printed page, then the text will wrap on-screen, too. (and the printed content will indeed match what you see on-screen)

(People worried about toner-waste can always check print-preview, if they like :))

> Zoom level has zero perceptible impact on this Linux
> system on printing.

Sorry, by "zoom" I meant "Scale" (the menu in the Print Preview UI, where Shrink-to-fit is the default. On my system, the "90%" option makes the attached testcase render with no extra wrapping.
  
> Why is it default?

Because it lets us react gracefully when there is content on the page that is *actually* too wide to render (per my first paragraph in this comment).
(sorry, meant to respond to this as well):
> I don't see what default has to do with anything.

Default matters because it means users will get "shrink-to-fit" behavior even if they didn't explicitly choose it, so if it renders text illegibly-small in common use cases, then that's a problem.

For example: if someone loads a text document which happens to have a long paragraph with no explicit newline characters, like this...
{
data:text/plain,This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines. This is a long paragraph, with no newlines.
}
...then the old (Firefox 21) no-wrapping behavior would make us render that entire paragraph all on one illegibly-small line.

The current behavior makes us wrap it when it hits the edge of the page, just as we wrap it in the browser-window when it hits the edge of the browser.
(Reporter)

Comment 15

4 years ago
(In reply to Daniel Holbert [:dholbert] from comment #13)
> So, in my understanding, the purpose/concept of Shrink To Fit in our print
> UI is:
 
> "See if there's any content that would normally trigger a horizontal
> scrollbar (or otherwise render out-of-bounds) when rendered to a printed
> page. Normally, we'd truncate this content, since we can't print a
> functional scrollbar or allow dynanmic browser-resizing in a printed page.
> So instead of truncating that content, adjust the zoom level such that it
> fits without needing a scrollbar."

Looks close enough to me, maybe s/zoom level/scale/ and s/ without needing a scrollbar//.
 
> > Not just annoying, but wasteful. I need what I see printed as I see it
> > displayed on screen.
 
> I take it you're looking at it in a browser that's > 8 inches wide. If you

It is whatever it is, because pixels don't have predictable dimensions, no predictable *size*. Points have a certain size, inches have a certain size, mm have a certain size, but pixels don't, at least not in human manageable fashion when translated to printed page. I make the viewport at least as wide as it needs to be to see the content as I expect it to look when printed, because I created the content as I did to fit a standard sheet of paper using  common type at a legible size, typically something in the 9pt to 12pt range. I don't need to actually measure the content, because the print vehicle, Gecko, unlike others I've tried, can automatically tweak the font size as necessary so that it does fit, and do so even if the printer's printable area is narrower than expected or the content a bit wider than expected.

It happens that my average browser window size is well over a half screen in area. The profile I do most plain text file printing from is usually kept fullscreen on a screen 52cm wide, nothing like a portrait letter sheet. ATM I have 3 browser windows fullscreen, 1 at about 96% of screen area, a 5th at about 88% of screen area, a 6th at about half screen area, and the 7th at about 1/3 of screen area. I use a big screen to make things big enough to see, not to fit more stuff on screen at once than fits on smaller screens.

> shrink your browser to the width of a printed page, then the text will wrap
> on-screen, too. (and the printed content will indeed match what you see
> on-screen)

That might be, but I'd hopefully discover the need to and fix the page before wasting resources that require money to pay for on unwanted wrapping. The test case is actually a result of my real world use, adapted to make it easier to understand what is happening when printed. The plain text I'm actually printing most of the time is exported tabular data from a spreadsheet (financial information or statistical data), so wrapping is simply not acceptable.
 
> (People worried about toner-waste can always check print-preview, if they
> like :))

As I noted in comment 6, print preview here @>96DPI is little better than useless. Page breaks almost never happen at points resembling those predicted by preview, and similar for margins/page width when shrink to fit is not enabled.

(In reply to Daniel Holbert [:dholbert] from comment #14)
> Default matters because it means users will get "shrink-to-fit" behavior
> even if they didn't explicitly choose it, so if it renders text
> illegibly-small in common use cases, then that's a problem.

What illegibly small describes looks like a justification to not have shrink to fit enabled by default, except I doubt such extreme as *illegibly* small is a very common case.
 
> For example: if someone loads a text document which happens to have a long
> paragraph with no explicit newline characters, like this...
> [>700 printable characters]
> ...then the old (Firefox 21) no-wrapping behavior would make us render that
> entire paragraph all on one illegibly-small line.

Surely as most who might try to print one line of 700+ characters would expect. Most people ought to know before trying to print at all that 700 legible characters shouldn't be expected to fit one line.

I don't think your example remotely resembles anything like a common use case. 

> The current behavior makes us wrap it when it hits the edge of the page,
> just as we wrap it in the browser-window when it hits the edge of the
> browser.

Shrink to fit needs to be an option that does what it purports to do. If no lines in the source wrap, then none should wrap in print output. If the printed result makes text illegibly small, then the source needs to be modified, or the paper orientation or size adjusted, not the definition of shrink to fit.
(Assignee)

Comment 16

4 years ago
(In reply to Daniel Holbert [:dholbert] from comment #10)
> (In reply to Mats Palmgren (:mats) from comment #2)
> > Still, I would expect "wrap wrong lines" to be disabled while printing
> > with "shrink to fit".
> 
> I disagree, specifically because "Shrink to fit" is the default, and it
> shouldn't have footguns. (And no-wrap printing is a footgun that leads to
> illegible (or effectively blank) printouts, as in bug 960822.)

I thought we already had a cap on much we scaled shrink-to-fit to
avoid things like that bug.  The reason I thought so is that bug
960822 doesn't occur for plain text documents.  Anyway, I agree
that adding a cap (so that the text is tiny but not invisible)
is a good idea.  That should make it obvious to the user when
shrink-to-fit isn't a good choice.

I think it's logical that shrink-to-fit disables wrap-long-lines.
The reason for that is that shrink-to-fit is a *print* setting and
thus should trump contradicting settings/preferences while printing.
(Assignee)

Comment 17

4 years ago
Created attachment 8368542 [details] [diff] [review]
Alternative patch

This fixes the bug for "text/plain" documents.
It doesn't fix it for view-source though, since they are text/html.
(Assignee)

Comment 18

4 years ago
What's the best way to figure out if a document/presshell/prescontext/docshell is
for "view source"?

nsHTMLDocument.cpp seems to have something internally, does it expose it somehow?
http://mxr.mozilla.org/mozilla-central/source/content/html/document/src/nsHTMLDocument.cpp#483
Flags: needinfo?(bzbarsky)
(Assignee)

Comment 19

4 years ago
Created attachment 8368568 [details] [diff] [review]
fix

This seems to work correctly for me.  (There's no reftest since
I don't think we have support for testing text files in print
mode in the reftest framework.)
Attachment #8368542 - Attachment is obsolete: true
Attachment #8368568 - Flags: review?(jaws)
I don't think we have any particular API for view source docs, since they're supposed to be like any other HTML document.
Flags: needinfo?(bzbarsky)
Also, why is this special to plaintext/viewsource?  Wouldn't normal web pages end up with the same behavior?

As in, what exactly is the bug?
(In reply to Felix Miata from comment #15)
> Surely as most who might try to print one line of 700+ characters would
> expect. Most people ought to know before trying to print at all that 700
> legible characters shouldn't be expected to fit one line.

The point is, the user doesn't necessarily know (and shouldn't need to know) that all of those characters happen to be on one line, because Desktop Firefox (along with pretty much any other text editor/viewer) will wrap the words nicely, and our printouts should be consistent with that behavior. 

> I don't think your example remotely resembles anything like a common use
> case. 

I'd dispute that. I'd bet that many folks writing plain-text don't bother to hardcode linebreaks into their content, given that all reasonable plain-text viewers will wrap the lines for them.

> Shrink to fit needs to be an option that does what it purports to do. If no
> lines in the source wrap, then none should wrap in print output. If the
> printed result makes text illegibly small, then the source needs to be
> modified, or the paper orientation or size adjusted, not the definition of
> shrink to fit.

Shrink to fit does not do what you think it does. It's purely to prevent content from being truncated, not to redefine how we do line-wrapping.
(In reply to Mats Palmgren (:mats) from comment #16)
> I thought we already had a cap on much we scaled shrink-to-fit to
> avoid things like that bug.  The reason I thought so is that bug
> 960822 doesn't occur for plain text documents.

It absolutely does occur for plain text documents -- at least, it does in Firefox 21 (before bug 253564 enabled text-wrapping in plain text documents).  I just verified that using my data URL from comment 14.

> Anyway, I agree
> that adding a cap (so that the text is tiny but not invisible)
> is a good idea.  That should make it obvious to the user when
> shrink-to-fit isn't a good choice.

That would probably be helpful, yeah.

> I think it's logical that shrink-to-fit disables wrap-long-lines.

I don't think that's what it's for, per end of comment 22.  (And as bz points out in comment 21, would you suggest we make it disable wrap-long-lines for HTML as well?)
(Assignee)

Comment 24

4 years ago
Created attachment 8368673 [details]
965692-3.txt

(In reply to Daniel Holbert [:dholbert] from comment #23)
> It absolutely does occur for plain text documents -- at least, it does in
> Firefox 21 (before bug 253564 enabled text-wrapping in plain text
> documents).  I just verified that using my data URL from comment 14.

It does occur for that data URL, yes.  I used a local text file and it
doesn't occur with this document for some reason.  When I Print or
Print-Preview this text file I get legible text, and the first line is
clipped (both in Nightly with wrap-long-lines turned off, and in FF20)
(Assignee)

Comment 25

4 years ago
(In reply to Boris Zbarsky [:bz] from comment #21)
> As in, what exactly is the bug?

Documents containing long lines that don't fit should be scaled
down until the lines fit when shrink-to-fit is requested.
The styling for plain text documents introduced in bug 253564
instead makes long lines line-wrap by breaking words, so it
essentially broke the shrink-to-fit print feature for plain
text documents.
(Assignee)

Comment 26

4 years ago
(let's ignore view-source in this bug, I'm not sure we need to do anything
there, and it certainly isn't related to this regression anyhow)
(In reply to Mats Palmgren (:mats) from comment #24)
> It does occur for that data URL, yes.  I used a local text file and it
> doesn't occur with this document for some reason.

(Odd, yeah -- I can confirm that, in Firefox 21, the first line of that attachment ends up normal-sized & clipped, with Firefox 21. It might be worth investigating (perhaps in another bug) what's going on there; but for now, that clipping seems like an additional reason to preserve our existing wrap-long-lines behavior here. :))

(In reply to Mats Palmgren (:mats) from comment #25)
> Documents containing long lines that don't fit should be scaled
> down until the lines fit when shrink-to-fit is requested.

Per the first part of bz's question, why would it make sense to *only* have this behavior for text/plain? (And how do you suggest we deal with printing cases like my data URI from comment 14? We clearly have to wrap there, or else there will be dataloss from either truncation or illegibly-small text.)
(Assignee)

Comment 28

4 years ago
(In reply to Daniel Holbert [:dholbert] from comment #23)
> I don't think that's what it's for, per end of comment 22.  (And as bz
> points out in comment 21, would you suggest we make it disable
> wrap-long-lines for HTML as well?)

No, because white-space is ignored in HTML.  Besides, we never enabled
wrap-long-lines for HTML, it's intrinsic. ;-)

White-space in plain text documents on the other hand have always been
*significant*, and traditionally been formatted as white-space:pre.

I do think wrap-long-lines is a nice feature though, but not when
the user is requesting that the lines *in the document* instead
should be scaled down to fit the available space.  There's no
need for wrap-long-lines in that case because they all fit.
(Assignee)

Comment 29

4 years ago
(In reply to Daniel Holbert [:dholbert] from comment #27)
> (And how do you suggest we deal with printing
> cases like my data URI from comment 14? We clearly have to wrap there, or
> else there will be dataloss from either truncation or illegibly-small text.)

I disagree we have to wrap there.  We should do what I suggested earlier -
put a cap on the scaling so that it will render as tiny but still visible
text so that it becomes obvious to the user that shrink-to-fit isn't
a good choice for this "document".
(Assignee)

Comment 30

4 years ago
(In reply to Daniel Holbert [:dholbert] from comment #27)
> (Odd, yeah -- I can confirm that, in Firefox 21, the first line of that
> attachment ends up normal-sized & clipped, with Firefox 21. It might be
> worth investigating (perhaps in another bug) what's going on there [...]

I filed bug 966419.  The bug also occurs for HTML.
(Reporter)

Comment 31

4 years ago
(In reply to Daniel Holbert [:dholbert] from comment #22)
> Desktop Firefox

IMO that's an enhanced editor, adaptive to context, not plain text.

> (along with pretty much any other text editor/viewer) will wrap the
> words nicely

NCEDIT (Norton Commander; probably first editor I used routinely) doesn't wrap.
DOS 5 Editor doesn't wrap.
Notepad (WinXP default editor) does not wrap by default.
Joe does not wrap.
Nano does not wrap.
Mcedit does not wrap (by default if at all) (one of my 2 most used text editors).
File Commander's internal editor does not wrap (by default if at all) (other of my 2 most used text editors).

IMO, not wrapping by default, if even possible to auto-wrap at all, is characteristic of a plain text editor. How could ASCII artists do what they do if wrapping was standard behavior?

> Shrink to fit does not do what you think it does. It's purely to prevent
> content from being truncated, not to redefine how we do line-wrapping.

I think from reading here Mats agrees it does do what I think.
(In reply to Mats Palmgren (:mats) from comment #28)
> I do think wrap-long-lines is a nice feature though, but not when
> the user is requesting that the lines *in the document* instead
> should be scaled down to fit the available space.

(As noted above, with our current defaults, most of the time, shrink-to-fit printing isn't an explicit "request" from the user. They probably just did File|Print and end up with defaults.)

(In reply to Mats Palmgren (:mats) from comment #29)
> I disagree we have to wrap there.  We should do what I suggested earlier -
> put a cap on the scaling so that it will render as tiny but still visible
> text so that it becomes obvious to the user that shrink-to-fit isn't
> a good choice for this "document".

That might work, though...
 (A) if the truncated text isn't until e.g. on Page 3, the user might not notice the truncation right away (and wouldn't be able to take the hint that shrink-to-fit is a bad choice)
 (B) Even if they do notice, it's non-obvious that it's possible for them to change things to fix the truncation. If default options give them scaled-down text that's still too wide & is truncated, it's unintuitive that picking "Scale: 100%" would be the way to avoid truncation.
(In reply to Felix Miata from comment #31)
> NCEDIT [etc.]

I was talking mostly about user-friendly graphical text editors, and had gedit as a local example (which does wrap by default). (I thought Notepad wrapped, but I don't have WinXP available to test, so I'll take your word for it).

In any case, my mention of other programs was a parenthetical; my point was more that Firefox *itself* wraps plain text now (by default), so it seems reasonable for it to match that behavior (by default at least) when printing.

> How could ASCII artists do what they do if wrapping was standard behavior?

Disable the "wrap" option in their text editor (gedit in my case), I guess? But as you say, non-wrapping editors are available, so I suppose they use one of those.

> > Shrink to fit does not do what you think it does. It's purely to prevent
> > content from being truncated, not to redefine how we do line-wrapping.
> 
> I think from reading here Mats agrees it does do what I think.

Well, clearly it does not do what you want, or else this bug wouldn't exist. :)

I'm describing the idea behind how "shrink to fit" traditionally has behaved, as I understand it (and what IMHO is the most consistent & least magical way for it to behave).

Mats appears to agree that it *should* do what you want, and has attached a patch to make it do so.
(Reporter)

Comment 34

4 years ago
(In reply to Daniel Holbert [:dholbert] from comment #33)
> In any case, my mention of other programs was a parenthetical; my point was
> more that Firefox *itself* wraps plain text now (by default), so it seems
> reasonable for it to match that behavior (by default at least) when printing.

This isn't about Firefox per se, but rather core. The only text editing I do in Firefox is occasionally within web page textareas, which tend to behave under some control of the web authors who embed them. This form happens to be being completed in SeaMonkey, as all my previous comments here were.
 
> > How could ASCII artists do what they do if wrapping was standard behavior?
 
> Disable the "wrap" option in their text editor (gedit in my case), I guess?
> But as you say, non-wrapping editors are available, so I suppose they use
> one of those.

Not just ASCII artists, but bookkeepers, accountants, bankers, financial analysts and other heavy users of columnar data, often output from spreadsheet apps, little or none of which can tolerate layout mutations.
 
> > I think from reading here Mats agrees it does do what I think.
 
> Well, clearly it does not do what you want, or else this bug wouldn't exist. :)

Equally clearly my previous comments suffered from some temporal discombobulation. :-( Indeed rv21 did what I needed, while without Mats' "Basic Page Style" workaround, newer cannot.
 
> I'm describing the idea behind how "shrink to fit" traditionally has
> behaved, as I understand it (and what IMHO is the most consistent & least
> magical way for it to behave).

Try convincing any CPA of that. :-p
Comment on attachment 8368568 [details] [diff] [review]
fix

Review of attachment 8368568 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not a peer in this area so I can't review this code.
Attachment #8368568 - Flags: review?(jaws)
You need to log in before you can comment on or make changes to this bug.