sw/source/core/doc/DocumentDeviceManager.cxx | 9 +++++++++
1 file changed, 9 insertions(+)
New commits:
commit 5042375a67a7c7171529abd9724576a269a0c32e
Author: Michael Weghorn <m.wegh...@posteo.de>
AuthorDate: Thu Nov 21 14:03:05 2019 +0100
Commit: Michael Weghorn <m.wegh...@posteo.de>
CommitDate: Thu Nov 21 22:01:16 2019 +0100
tdf#118263 Take over doc print options for new printer
Take over the current document-specific print settings for
a newly created printer in 'sw::DocumentDeviceManager::Create_Printer_'.
This makes sure that the options of an 'SfxPrinter*' retrieved
by calling 'DocumentDeviceManager::getPrinter(true)' are in line
with the 'SwPrintData' currently set.
This among other fixes the issue described in tdf#118263,
comment 7, i.e. the options shown in "File" -> "Printer Settings"
-> "Options" were not properly initialized when the config option
for loading user-specific settings with the document was disabled.
(All checkboxes were unchecked in the UI in this case instead of
showing the default values.)
What happens is that when importing the document,
'bPrinterIndependentLayout' in 'SwXMLImport::SetConfigurationSettings'
is 'false', so that this block is entered there:
if( ! bPrinterIndependentLayout )
{
xProps->setPropertyValue( "PrinterIndependentLayout",
Any(sal_Int16(document::PrinterIndependentLayout::DISABLED)) );
}
resulting in the following call stack where the printer is created and
set:
#0 sw::DocumentDeviceManager::setPrinter(SfxPrinter*, bool, bool)
#1 sw::DocumentDeviceManager::CreatePrinter_() const
#2 sw::DocumentDeviceManager::getPrinter(bool) const
#3 sw::DocumentDeviceManager::setReferenceDeviceType(bool, bool)
#4 SwXDocumentSettings::_setSingleValue(comphelper::PropertyInfo
const&, com::sun::star::uno::Any const&)
#5 comphelper::MasterPropertySet::setPropertyValue(rtl::OUString
const&, com::sun::star::uno::Any const&)
#6
SwXMLImport::SetConfigurationSettings(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>
const&)
[...]
Writer's default settings were not applied in this case.
For the case where loading user-specific settings is enabled,
no printer is set at this stage, but it's later set in the call to
'SwView::GetPrinter', in which case there is already an explicit
call to 'SetAppPrintOptions' after the printer is created via
'DocumentDeviceManager::getPrinter(true)', so all was fine there
earlier as well.
(Apparently, the same issue could be reproduced with the config
option for loading user-specific options enabled, but an ODT
document that has "PrinterIndependentLayout" set to "disabled"
in it's settings.xml.)
Change-Id: I39fd300fb56b767e7103b65537b0eac1365e5fd7
Reviewed-on: https://gerrit.libreoffice.org/83394
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.wegh...@posteo.de>
(cherry picked from commit 46f8f48ebfe25e26b4d1c0718c772abbee70b889)
Reviewed-on: https://gerrit.libreoffice.org/83428
diff --git a/sw/source/core/doc/DocumentDeviceManager.cxx
b/sw/source/core/doc/DocumentDeviceManager.cxx
index e0c0b7d09be8..18da1249341c 100644
--- a/sw/source/core/doc/DocumentDeviceManager.cxx
+++ b/sw/source/core/doc/DocumentDeviceManager.cxx
@@ -34,6 +34,7 @@
#include <printdata.hxx>
#include <vcl/mapmod.hxx>
#include <svl/itemset.hxx>
+#include <cfgitems.hxx>
#include <cmdid.h>
#include <drawdoc.hxx>
#include <wdocsh.hxx>
@@ -297,6 +298,14 @@ SfxPrinter& DocumentDeviceManager::CreatePrinter_() const
FN_PARAM_ADDPRINTER, FN_PARAM_ADDPRINTER>{});
VclPtr<SfxPrinter> pNewPrt = VclPtr<SfxPrinter>::Create( std::move(pSet) );
+
+ // assign PrintData to newly created printer
+ const SwPrintData& rPrtData = getPrintData();
+ SwAddPrinterItem aAddPrinterItem(rPrtData);
+ SfxItemSet aOptions(pNewPrt->GetOptions());
+ aOptions.Put(aAddPrinterItem);
+ pNewPrt->SetOptions(aOptions);
+
const_cast<DocumentDeviceManager*>(this)->setPrinter( pNewPrt, true, true
);
return *mpPrt;
}
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
