While such massive sizes are probably a bug in windows, we're already
dealing with failure gracefully, so no need to crash the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D167931
All implementors currently simply resolve the promise right away, using
crutch code. Asynchronous usage will be added in the changeset that follows.
Differential Revision: https://phabricator.services.mozilla.com/D163508
Compared to other platforms, on "printing" PDF files, Windows writes straight
to the destination path. This causes the mainthread to become less responsive
if the path is slow (e.g. Network drive over VPN).
This still causes a mainthread block at the time the file is moved, but:
- Brings Windows' behaviour in line with other platforms
- Avoids `PrintTargetPDF` becoming async, which is less meaningful on
other platforms
- Reduces the async site to one (i.e. moving to destination path)
Differential Revision: https://phabricator.services.mozilla.com/D163506
The default value for the pref print.default_dpi in StaticPrefList.yaml is
already 144. Having this override simply prevents that pref from working on
Windows.
Differential Revision: https://phabricator.services.mozilla.com/D146828
The trickiest bits are the PrintTargetCG ones, the rest is just plumbing
and cleanups and tests, but let me know if you want those to be split
out, can do.
The GTK change to nsPrintSettingsGTK::GetResolution is a no-op (we only
read resolution on windows), but I did that because we assume that it
doesn't fail and GTK returns a sane default anyways.
Differential Revision: https://phabricator.services.mozilla.com/D142199
The trickiest bits are the PrintTargetCG ones, the rest is just plumbing
and cleanups and tests, but let me know if you want those to be split
out, can do.
The GTK change to nsPrintSettingsGTK::GetResolution is a no-op (we only
read resolution on windows), but I did that because we assume that it
doesn't fail and GTK returns a sane default anyways.
Differential Revision: https://phabricator.services.mozilla.com/D142199
Also, for GTK, request the paper size in millimeter for
millimeter based paper units to avoid depending on GTK's
rounding behavior.
Differential Revision: https://phabricator.services.mozilla.com/D103609
This patch does three things, all centered around these new APIs:
(1) Add the APIs themselves -- some nsIPrintSettings methods to reason about
the sheet-orientation being potentially flipped to accomodate 2 and 6
pages-per-sheet.
(2) Use these new APIs, where appropriate, in places where we previously used
the page-orientation to set up the platform-native print-settings objects and
print-target. Now, we'll use the *sheet* orientation instead of the page
orientation, to be sure we produce the appropriately-oriented platform-native
surfaces. Also, for symmetry, this patch adds similar logic to the reverse
codepaths, where we update an existing nsIPrintSettings object based on a
platform-native print-settings object.
(3) Update nsPrintJob's code that informs nsPresContext about the page-size.
This patch makes sure that this code uses the *page* size, rather than the
*sheet* size, in cases where they differ. (The code that consumes this
nsPresContext::GetPageSize API, e.g. our CSS media-query code, really does want
the page size, not the sheet size.)
Differential Revision: https://phabricator.services.mozilla.com/D100372
This should be able to avoid creating a printer-specific HTTP connection in
nsPrinterCUPS::DefaultSettings when the paper size is a PWG-recognized size.
The current maximum error when comparing paper sizes is 4 points. This may need
to be revised later.
Differential Revision: https://phabricator.services.mozilla.com/D91497
This also renames nsIPrinterList.getNamedPrinter to nsIPrinter.getPrinterByName
for consistency.
This is cheaper to lookup on platforms that use CUPS and do not show the Unix
name for printers. This only applies to OS X at the present.
Differential Revision: https://phabricator.services.mozilla.com/D90201
This also doubles the memory we allocate for DEVMODEs, when that value has been
returned from the other uses of DocumentProperties, because apparently some
drivers do not return the correct size.
Differential Revision: https://phabricator.services.mozilla.com/D90251
I've tested both webpage printing and pdf printing, in both the new UI
and the system dialog, and this gives consistently better results,
specially when images are involved.
I've put the exact DPI value on a pref because I think that's the
sensible thing to do, and allows us to test higher resolutions too.
Differential Revision: https://phabricator.services.mozilla.com/D89805
I intentionally removed the "move the default printer to the front" in
windows because that's not a guarantee that we provide in CUPS, but lmk
if you want it back.
I have zero idea about why the GlobalPrinters code was so ridiculously
complex.
Depends on D86396
Differential Revision: https://phabricator.services.mozilla.com/D86397
This includes adding nsPrinterWin and nsPaperWin, so that we can retrieve
information from the printer device lazily.
Differential Revision: https://phabricator.services.mozilla.com/D84009
The `systemDefaultPrinter` attribute in `nsIPrinterList` currently has
only one usage: to retrieve the printer's name. This patch changes the
attribute to be the name instead of the whole printer until such
funcationality is needed.
Differential Revision: https://phabricator.services.mozilla.com/D82951
- Add new interface for `nsIPrinter`.
- Add readonly attribute for printer name.
- Add implementation of interface: `nsPrinter`.
- Rename `nsIPrinterEnumerator` to `nsIPrinterList`.
- Refactor `nsIPrinterList` to use `nsIPrinter`.
Differential Revision: https://phabricator.services.mozilla.com/D81414
Jonathan Kew