Issue 80835 - settings.xml config-item PrinterSetup :: What's in it?
Summary: settings.xml config-item PrinterSetup :: What's in it?
Alias: None
Product: Writer
Classification: Application
Component: printing (show other issues)
Version: OOo 2.3
Hardware: All All
: P2 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2007-08-20 02:48 UTC by rag56
Modified: 2017-05-20 11:19 UTC (History)
3 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description rag56 2007-08-20 02:48:59 UTC
Looking at the "PrinterSetup" config-item in the settings.xml file of OOo/odt 
documents I notice that it contains a binary chunk of data encoded as base64.

I would like to know more details about the format of that data and how it is 
written.  Specifically, I'm trying to track down some printer tray related 

The only documentation I have found so far is this general description:

Is there a more detailed specification or anything else available?

Thanks a bunch for any information provided.
Comment 1 michael.ruess 2007-08-20 07:58:48 UTC
Reassigned to ES.
Comment 2 eric.savary 2007-08-20 11:53:41 UTC
Please address questions to the Not to the issue tracker.
Than you!
Comment 3 eric.savary 2007-08-20 11:53:58 UTC
Comment 4 rag56 2007-09-13 18:53:51 UTC
There is no specification that fully documents the contents of the binary blob 
stored in PrinterSetup.  That is a valid issue.
Comment 5 eric.savary 2007-09-18 11:57:58 UTC
@MBA: s/t to do with the XML-spec?
Comment 6 rag56 2007-09-18 14:43:12 UTC
The ODF spec says that settings.xml contains "Application-specific settings, 
such as the window size or printer information."

This means that the definition of the contnets of the PrinterSetup config-item 
comes from OpenOffice, not ODF.

The definition from the OpenOffice API spec says:

"This property serves to capture the current printer setup settings, such as 
paper tray, printer options, etc. The data can typically be interpreted only by 
the system that generated it. The PrinterSetup property may be used to save and 
restore the user's printer settings."

However, there is nothing that formally defines the binary content stored in 
the PrinterSetup config-item.  I want to parse that content.  Unfortunately, it 
is in a binary format, not xml.  So, it can not be deciphered without a proper 
specification, of which none exists.

Comment 7 Mathias_Bauer 2008-03-27 14:46:11 UTC
Oliver, is there something we could do here?
Comment 8 Mathias_Bauer 2008-05-16 16:35:26 UTC
Sorry, there is something totally wrong. "P2" and "OOoLater" don't match.

So we must clarify the importance of this issue. Michael, Oliver: what about this? 

Michael: is it OK from the ODF point of view that this data is unspecified? If
no,  then "P2" is correct and we should change the target to "3.0". If yes, than
we should turn "P2" in "P3" or "P4".

In case we opted for "yes" - Oliver: Can we do something here and how much
effort is it. Depending on this answer I would either keep the "OOolater" target
or change it to "3.x".
Comment 9 Oliver Specht 2008-05-17 14:40:04 UTC
The data is created from vcl. See SvStream& operator<<( SvStream&, const
JobSetup& ) in vcl/source/gdi/jobset.cxx
Comment 10 michael.brauer 2008-12-19 13:18:56 UTC
My opinion is: We should document the binary content to the degree we can. For
instance: If we get some data let's say through an Windows or X11 API, then we
should state that, but we should not repeat what is said in the documentation of
the API. If we add our own data, then we should state that as well.
Comment 11 Mathias_Bauer 2009-01-05 12:18:13 UTC
Where should we document this?
Comment 12 Oliver Specht 2009-06-17 14:29:20 UTC
->pl: The stream operator looks as if we know more about the content. It might
make sense to store it in xml.
Comment 13 philipp.lohmann 2009-06-17 15:24:57 UTC
Storing the jobsetup partially in XML incidentally would violate the ODF spec as
it is, wouldn't it ? Anyway that would be a file format change.

The current text is quite right: the binary blob is mostly what comes out of a
printer driver; it's a DEVMODE structure on Windows. On other systems its is
also some blob known only to the printer implementation.

Garnished around that are a few vcl internal enums caching parts of the driver
blob as they come out of system dependent print API accessing that blob.

On top of that this is data that can be used only on the same system and the
same printer, a method to store driver settings you can access through the
native print driver dialogs. That it is stored in the actual document stream is
more of a historical accident IMHO, this would have belonged into meta data (if
we had had them at the time ;-) )
Comment 14 philipp.lohmann 2009-06-17 15:27:38 UTC
so how about removing this ill defined object and move it into the meta data ?
Comment 15 Marcus 2017-05-20 11:19:33 UTC
Reset assigne to the default "".