We integrate PrintTargetEMF with the PDFium process to convert PDF into EMF in
this patch.
MozReview-Commit-ID: 5F0setrL94n
--HG--
extra : rebase_source : 1e52adbbe7502ca081c7029a15e4b3f486beb284
extra : source : 28f1671230fa70125e6971c9a287cb0658b89496
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : c64c4d39ccca16271959ade57edc2a8a087141b8
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
We integrate PrintTargetEMF with the PDFium process to convert PDF into EMF in
this patch.
MozReview-Commit-ID: 5F0setrL94n
--HG--
extra : rebase_source : 3dfc6ce64f4cdc7d5d7e95d1f064d956af909a26
extra : source : 28f1671230fa70125e6971c9a287cb0658b89496
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : 92276c366e3e8faa9be7a43fa64c2c5c56a7014b
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
We integrate PrintTargetEMF with the PDFium process to convert PDF into EMF in
this patch.
MozReview-Commit-ID: 5F0setrL94n
--HG--
extra : rebase_source : 576e077f804785da20923620d9c4e3041936e835
extra : source : 28f1671230fa70125e6971c9a287cb0658b89496
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : b6459a187de8e066e7574d2b8757d09fbcfcddba
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
This does not remove the directives in widget/ContentCache.cpp as those crash
annotations should be temporary and will be removed once bug 1405832 is fixed.
MozReview-Commit-ID: F0STyYDx8F4
--HG--
extra : rebase_source : 737d3e500e1dd066730660fede52226e832305e6
C5038 is a new warning in VS2017, similar to gcc and clang's -Wreorder, which is enabled by -Wall. We should enable C5038 so Windows developers can see these warnings locally instead of when gcc and clang fail with warnings-as-errors on Try.
https://blogs.msdn.microsoft.com/vcblog/2017/07/21/diagnostic-improvements-in-vs2017-15-3-0/
We need to suppress C5038 warnings from Windows Runtime Library header files (wrl.h) included in ANGLE and widget/windows:
z:\build\build\src\vs2017_15.4.2\SDK\Include\10.0.15063.0\winrt\wrl\wrappers\corewrappers.h(515): error C5038: data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::sync_' will be initialized after data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::status_'
...
And suppress C5038 warnings in upstream webrtc code:
media/webrtc/trunk/webrtc/modules/video_capture/windows/BaseFilter.cpp(176): error C5038: data member 'mozilla::media::BaseFilter::mClsId' will be initialized after data member 'mozilla::media::BaseFilter::mState'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(169): error C5038: data member 'mozilla::media::BasePin::mFilter' will be initialized after data member 'mozilla::media::BasePin::mLock'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(170): error C5038: data member 'mozilla::media::BasePin::mLock' will be initialized after data member 'mozilla::media::BasePin::mName'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(172): error C5038: data member 'mozilla::media::BasePin::mDirection' will be initialized after data member 'mozilla::media::BasePin::mQualitySink'
MozReview-Commit-ID: BMDVkvQXNoq
--HG--
extra : rebase_source : 0d5ede9530d0d0750b8fffdc1cdfdc646ec8f22a
This patch will
* Move native print dialog code to the PrintDialogService of widget.
* Toolkit call PrintDialogService instead of calling the native print dialog.
* Change SetWindowText/CreateWindow to SetWindowTextW/CreateWindowW
in order to treat localized string correctly.
MozReview-Commit-ID: DOgp3STaJ4t
--HG--
rename : toolkit/components/printingui/win/nsPrintDialogUtil.cpp => widget/windows/nsPrintDialogUtil.cpp
rename : toolkit/components/printingui/win/nsPrintDialogUtil.h => widget/windows/nsPrintDialogUtil.h
extra : rebase_source : 9b428f528156a70f5a127b1eeec60f6f593387a0
In order to move print native dialog code to windows widget, this patch will
create skeleton of PrintDialogService to windows widget.
Toolkit code(i.e. nsIPrintingPrompotService) will call this PrintDialogService.
Note that this PrintingDialogService suppose running on main process, so we
should call this interface from main process(i.e. nsPrintingPromptService, not
nsPrintingProxy).
MozReview-Commit-ID: 3P6kac9I9W4
--HG--
extra : rebase_source : 5b5ecd104cf4cecd1b68a3d6d4b33aca9fea9548
1.PDfium would be built into the xul (bug 1368948) so PDFiumEngineShim could
call functions directly. However, I still keep loading dynamic library for
debugging purpose. Create a new preference for storing the library file path.
2.Remove redundant define and typedef which are written in PDFium head file.
3.Include an appropriate head file from PDFium.
4.Remove non-used PDFium APIs.
5.Use the singleton pattern to retrieve the instance of PDFiumEngineShim.
6.Don't destroy the library inside PDFiumEngineShim::CloseDocument because the
library has to deal with multi-document.
MozReview-Commit-ID: 97ZBFp1qU8V
--HG--
extra : rebase_source : a60ee37906a94788e0baabbb95bd8848eca096af
This class helps draw a PDF file to a given Windows DC.
MozReview-Commit-ID: IjZAIcN3bND
--HG--
extra : rebase_source : 035dfbf5380316aacae8e1e1591d81971c47b843
This class exposes an interface to PDFium library and takes care of loading and
linking to the appropriate PDFium symbols.
MozReview-Commit-ID: 32jZD6d0KFw
--HG--
extra : rebase_source : 1d0580cbc8dc8687656ce32654d679da54104a33
WindowsEMF could be initialized with the path of a file where the EMF data
should be stored. If pass null point to the constructor that means the EMF data
are store in memory. Consumers can call GetDC() to get a HDC. It can be drawn to
generate the EMF output. After finishing with the HDC, call FinishDocument() to
finish writing the EMF output. Then consumers can call Playback() to play the
EMF's drawing commands onto the given DC. Once consumers don't use WindowsEMF
anymore, call ReleaseEMFHandle() to release object's handle. If the EMF output
is in memory, it is deleted. If it is on disk, it is not.
Consumers also can initialize WindowsEMF with an existing EMF file. They can
only use Playback().
MozReview-Commit-ID: 8hUsx8b2CXz
--HG--
extra : rebase_source : 99e38e61a00bfae45ec9102b3b23a095a7f3af1e
ScreenHelperWin is the platform dependent part of the original
nsScreenManagerWin and nsScreenWin. It listens the WM_DISPLAYCHANGE
message and pushes updates to ScreenManager. See patch part 4. for how
ScreenManager works.
MozReview-Commit-ID: 20A3ZQKmH9a
--HG--
rename : widget/windows/nsScreenManagerWin.cpp => widget/windows/ScreenHelperWin.cpp
rename : widget/windows/nsScreenManagerWin.h => widget/windows/ScreenHelperWin.h
extra : rebase_source : a3058c237d38f72103251802ab5f5bbd672e9b70
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
sotaro
Jonathan Watt
cku
Sylvestre Ledru
Cosmin Sabou
Bogdan Tara
Gabriele Svelto
shindli
Chris Peterson
Mantaroh Yoshinaga
Farmer Tseng
Phil Ringnalda
Bruce Sun
Brendan Dahl
Karl Tomlinson
Farmer Tseng
Joel Maher
Kan-Ru Chen
Stone Shih
Carsten "Tomcat" Book
Tom Tromey
David Anderson