Talk:Comparison of OpenXPS and PDF

This article was nominated for deletion on 12 July 2009 (UTC). The result of the discussion was keep.

This page was proposed for deletion by an editor in the past.

	This redirect is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This redirect has been rated as Low-importance on the project's importance scale.
	This redirect is supported by WikiProject Software (assessed as Low-importance).

Errors in PDF column

The PDF column has numerous errors. I am not sure how best to fix them and since I have serious doubts about the value of this article I'm not going to try right now. Here goes:

"Langage Type: Subset of PostScript page description programming language". This is false. The PDF language has roots in PostScript but it is not at all a subset. If it were, then you would be able to execute all PDF files in a PostScript interpreter.

I took this from Portable Document Format#Technical foundations. If you have a reference that confirms that PDF does use the full PostScript programming language, then please correct the article and add that reference. I'm going to add more references for the rest of the article ASAP. Thanks. Ghettoblaster (talk) 23:49, 5 July 2009 (UTC)[reply]

The referenced statement is that PDF "combines three technologies" of which one is "a subset of PostScript". That is true. That does not make PDF itself a subset of PostScript. It means it incorporated parts of PostScript in its original design. There is much, much more to the PDF language than that. Mrhsj (talk) 03:20, 6 July 2009 (UTC)[reply]

"Full file content compression: Compression at page level only". First I have no idea why "full file" vs "page level" is even interesting: what is interesting is how the file sizes compare for comparable content. But in any case it is not true to say PDF only has "compression at page level." All the non-stream objects in the whole file can be put into a stream and compressed as a unit.
"Multiple documents in one file: No". False. Multiple documents can be placed in the PDF file using the file attachment mechanism.
"Alpha channel in color definitions: no". Misleading at best. PDF supports full vector transparency. Syntactically it's expressed by putting alpha in the graphics state rather than the setcolor operator but that is functionally equivalent.
"Change Tracking: No". Debatable, depending on what you mean by change tracking. If a PDF is modified entirely via incremental updates, the entire history of the file can be recovered programmatically. In practice, I believe this is rarely done.

Mrhsj (talk) 22:51, 5 July 2009 (UTC)[reply]

Lrosenthol's recent edits addressed all my concerns. Mrhsj (talk) 16:56, 8 September 2009 (UTC)[reply]

Also, claiming that PDF doesn't support TIFF is incorrect. It is the uncompressed basis for images in the PDF the format. —Preceding unsigned comment added by 76.10.166.8 (talk) 23:29, 20 July 2010 (UTC)[reply]

Adobe introduced the XML Data Package in 2003. To-date, this is used as an XML form generator. The point being that PDF does have XML capabilites to some degree (although not natively).69.146.144.86 (talk) 05:09, 15 August 2012 (UTC)[reply]

Original Research?

I've tagged this article with WP:NOR because it cites no sources and may be an original synthesis. Mrhsj (talk) 22:55, 5 July 2009 (UTC)[reply]

Well, most of it is easy to check via the linked standard specifications. I'm going to add more references ASAP as mentioned above. Ghettoblaster (talk) 23:51, 5 July 2009 (UTC)[reply]

Development goals?

The article states "The different goals in the development of OpenXPS and PDF resulted in different principles and design tradeoffs between the file formats.". It would be nice if the article actually said what these different development goals are; I can't really tell from the table. -IByte (talk) 00:04, 27 January 2010 (UTC)[reply]

Seconded in the strongest possible terms. --SmartShark (talk) 22:02, 13 April 2012 (UTC)[reply]

+1 to that - what are the different goals? — Preceding unsigned comment added by 106.70.245.240 (talk) 05:25, 31 July 2012 (UTC)[reply]

+2 to this, especially since it is not backed by any references....where is this coming from? How does anyone know they had different design goals? Perhaps a guy at MS just didn't like Adobe? — Preceding unsigned comment added by 195.67.9.1 (talk) 13:05, 23 April 2014 (UTC)[reply]

Still no evidence offered or explanation of this claim. Stub Mandrel (talk) 15:12, 18 July 2018 (UTC)[reply]

The different principles and design tradeoffs between the file formats are actually described very well in the referenced whitepaper on page 2 and 3 [1]

I agree that aspects from that reference could be added to the article to better support the statement above:

A PDF file is made of a sequence of objects identified by numbers, followed by an index table containing the location of each object. This file format was designed for very fast viewing and printing. Its main inconveniences are:

Extracting document contents in a meaningful way for analysis purposes can be very painful as the content is not structured.
A larger file size because only fragments of the file are compressed.
…

An XPS file is made of a sequence of objects identified by URIs (Uniform Resource Identifiers.) The URI can be of the format /images/image1.jpg. The objects are stored in a regular ZIP file where all the object descriptions and object contents are compressed. The objects in a ZIP files are not indexed which makes access to an object much slower than in the case of PDF. This XML based format was designed to be easily extensible by simply adding attributes or objects to the schema. Packaging XPS documents as a ZIP file makes the manipulation of XPS files much easier:

Images and fonts are stored in their original format without the need for the extra processing that is required by PDF.
The XML parts can be easily edited even with a simple text editor.
…

Ghettoblaster (talk) 18:50, 18 July 2018 (UTC)[reply]

PDF feature check list here is rather shortened

Adobe PDF has a lot of features other than those mentioned here: eg: Form processing, posting those forms to URLs saving them in separate files (filesystem access), attaching/embedding files of any type, XHTML, CSS, Javascript, usage auditing, flash, video, audio embedding.

The lack of all these features in the table makes the two formats look very similar.

Of course some things on that list might lead one to think Microsoft were right to write their own PDF clone; despite it being "XML based". 90.195.73.153 (talk) 08:13, 16 September 2010 (UTC)[reply]

No equivalent of PS Core Font Set in OpenXPS worth mentioning?

AFAIK, there is no equivalent to the PostScript Core Font Set in OpenXPS, IMHO it might be worth mentioning. --77.117.247.173 (talk) 13:31, 13 August 2012 (UTC)[reply]

still valid?

With the release of the new Windows 8 OS, and an updated OpenXPS, are the version comparisons still totally valid here?69.146.144.86 (talk) 22:22, 25 November 2012 (UTC)[reply]