Bugzilla

In reply to David Shin[:dshin] from comment #7)
> At this moment, `pdf.js` looks to be using `@page { margin: 0; }`, which we honor, ignoring unwriteable margins (Though see bug 1681206)

Aha, right. I had forgotten that "Default" existed & was special here.

So this mitigates my concern (3) to some extent ("..we really do need to offer a true "Margins:None" option") -- we do offer such an option, but we just call it "Default" instead of "None"; and "None" does something quite-different-from-what-you-might-expect.

> However, if any option apart from `Default` was persisted [...] we will nudge and scale the PDF document out of unwriteable margins, which does not seem ideal. Filed bug 1782240.

Thanks!

> it's also an option to simply remove "Margins: None" option, which is a lot less complexity but less futureproof, potentially

That's hypothetically an option, yeah (particularly since "none" is just an alias for "0 0 0 0" and stored-as-such).  I don't love that, but it'd be arguably more-coherent than our current setup where we have "None|Minimum" which are ~equivalent (and which makes "None" feel mislabeled).

(In reply to Jonathan Kew [:jfkthame] from comment #8)
> I feel (pretty strongly, actually) that explicitly-specified margins, whether 0 or non-zero, should be honoured as specified, and *not* adjusted to force them within the printable area.

I somewhat agree -- that's concern (2) from comment 6 -- but I think we need to tread cautiously there since it's got a risk of causing dataloss/user-frustration from saved settings (in particular 0/0/0/0) suddenly causing clipping & dataloss.  I also think we can potentially address this bug's "None" concerns separately & without that risk (e.g. via proposal in comment 6, or even via removing None as David noted).

So: I spun this custom-margin-handling question off to bug 1782240.

In reply to David Shin[:dshin] from comment #7)
> At this moment, `pdf.js` looks to be using `@page { margin: 0; }`, which we honor, ignoring unwriteable margins (Though see bug 1681206)

Aha, right. I had forgotten that "Default" existed & was special here.

So this mitigates my concern (3) to some extent ("..we really do need to offer a true "Margins:None" option") -- we do offer such an option, but we just call it "Default" instead of "None"; and "None" does something quite-different-from-what-you-might-expect.

> However, if any option apart from `Default` was persisted [...] we will nudge and scale the PDF document out of unwriteable margins, which does not seem ideal. Filed bug 1782240.

Thanks!

> it's also an option to simply remove "Margins: None" option, which is a lot less complexity but less futureproof, potentially

That's hypothetically an option, yeah (particularly since "none" is just an alias for "0 0 0 0" and stored-as-such).  I don't love that, but it'd be arguably more-coherent than our current setup where we have "None|Minimum" which are ~equivalent (and which makes "None" feel mislabeled).

(In reply to Jonathan Kew [:jfkthame] from comment #8)
> I feel (pretty strongly, actually) that explicitly-specified margins, whether 0 or non-zero, should be honoured as specified, and *not* adjusted to force them within the printable area.

I somewhat agree -- that's concern (2) from comment 6 -- but I think we need to tread cautiously there since it's got a risk of causing dataloss/user-frustration from saved settings (in particular 0/0/0/0) suddenly causing clipping & dataloss when we make that hypothetical change.  I also think we can potentially address this bug's "None" concerns separately & without that risk (e.g. via proposal in comment 6, or even via removing None as David noted).

So: I spun this custom-margin-handling question off to bug 1782240.

In reply to David Shin[:dshin] from comment #7)
> At this moment, `pdf.js` looks to be using `@page { margin: 0; }`, which we honor, ignoring unwriteable margins (Though see bug 1681206)

Aha, right. I had forgotten that "Default" existed & was special here.

So this mitigates my concern (3) to some extent ("..we really do need to offer a true "Margins:None" option") -- we do offer such an option, but we just call it "Default" instead of "None"; and "None" does something quite-different-from-what-you-might-expect.

> However, if any option apart from `Default` was persisted [...] we will nudge and scale the PDF document out of unwriteable margins, which does not seem ideal. Filed bug 1782240.

Thanks!

> it's also an option to simply remove "Margins: None" option, which is a lot less complexity but less futureproof, potentially

That's hypothetically an option, yeah (particularly since "none" is just an alias for "0 0 0 0" and stored-as-such).  I don't love that, but it'd be arguably more-coherent than our current setup where we have "None|Minimum" which are ~equivalent (and which makes "None" feel mislabeled).

(In reply to Jonathan Kew [:jfkthame] from comment #8)
> I feel (pretty strongly, actually) that explicitly-specified margins, whether 0 or non-zero, should be honoured as specified, and *not* adjusted to force them within the printable area.

I somewhat agree -- that's concern (2) from comment 6 -- but I think we need to tread cautiously there since it's got a risk of causing dataloss/user-frustration from saved settings (in particular 0/0/0/0) suddenly causing clipping & dataloss when we make that hypothetical change.  I also think we can potentially address this bug's "None" concerns separately & without that risk (e.g. via proposal in comment 6, or even via removing None as David noted).

So: I spun this custom-margin-handling question off to bug 1782268.