Re: [ietf-types] Request for review of standards tree registration request for OpenXPS
Paul Libbrecht <paul@hoplahup.net> Mon, 31 January 2011 20:55 UTC
Return-Path: <paul@hoplahup.net>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD1A3A6C4D for <ietf-types@core3.amsl.com>; Mon, 31 Jan 2011 12:55:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.691
X-Spam-Level:
X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC9jMcJ5HJNx for <ietf-types@core3.amsl.com>; Mon, 31 Jan 2011 12:55:41 -0800 (PST)
Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by core3.amsl.com (Postfix) with ESMTP id 4CD7F3A6AEB for <ietf-types@ietf.org>; Mon, 31 Jan 2011 12:55:41 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p0VKwKWT017862 for <ietf-types@iana.org>; Mon, 31 Jan 2011 12:58:41 -0800
Received: from ip-2-204-35-50.web.vodafone.de (ip-2-204-35-50.web.vodafone.de [2.204.35.50]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0M2YnR-1Q0RqU1BuH-00sO4p; Mon, 31 Jan 2011 21:58:19 +0100
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="iso-8859-1"
From: Paul Libbrecht <paul@hoplahup.net>
In-Reply-To: <FE6603D65048F44AB8F8955AE89A09B9171E69CD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
Date: Mon, 31 Jan 2011 21:56:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1EA27F8-6BEB-4C20-B2B9-A55FAD47EC7A@hoplahup.net>
References: <FE6603D65048F44AB8F8955AE89A09B90A400D@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <F59FFEBA-9E75-4C2F-A34E-BAED919CA1FF@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9171E1E84@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <E8E16ECE-F281-48EE-8B70-F1D2FAB85037@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9171E69CD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
To: Brian Clubb <bclubb@microsoft.com>
X-Mailer: Apple Mail (2.1082)
X-Provags-ID: V02:K0:5C3WDTURHtrVV475SoF4ocQlH/5pNkPtOu9kwsxS767 bLgsVa5xlWnuJYFjWlPu+R9YI+sgoz3+o/r0UlFaow+EJpNV+6 +qFJ+esZ7CQVgzqSxJbkBNfYLMBRvnQYaAdhykOXjSgwzh4Egu qKXnICVJ9YB/eMRhUvzlGr2On4RXrVz5h78vRdI6BXQoY7v9En WCDtiBa0mn7W7eP24TSqYHpz2vF8HbyCf/PdyoP1xo=
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Mon, 31 Jan 2011 12:58:41 -0800 (PST)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2011 20:55:43 -0000
Hello Brian, Le 31 janv. 2011 à 19:33, Brian Clubb a écrit : > While the OpenXPS package contains XML, the document itself requires the hierarchical tree structure of pages and resources to be functional. It is intended that only a complete OpenXPS document would ever be posted to the clipboard. Sure. Only well formed data here (and well formedness is more than XML's). > Posting a fragment of an OpenXPS file to the clipboard would not be a useful scenario in the same way that I understand it would work in MathML or SVG. The resource tree in OpenXPS is integral to its functionality. But that is clear. It doesn't remove the usefulness of such a thing. As I said, PDF is the preferred flavor for vector graphics on MacOSX. And rest assured that copying from a page of a 200 pages book with Apple Preview does not create a PDF with many pages when copying a rectangle. Earlier examples on the mac of such transfers include the PICT format and the Adobe "AIFB" (?? I think ??) format which was taken huge time to be produced when you had just copied something, say, in PhotoShop and was switching away from it (in MaOS 7-9, I suppose the same must have been done on Windows). > For example, copying the XML for a fixed page out of one file onto the clipboard would not take into account the image and font resources which are stored in other locations in the OpenXPS file. That's the duty of the clipboard exporter. A normal composition programme can do that but viewers may have difficulties "at first", this is true. In the very same fashion copying html in a browser also inlines all the styles (even coming from very far from this element) when going out to, say, an email or word-processing application (in html or rtf). > Furthermore, re-integrating that page markup into the structure of another OpenXPS file would be extraordinarily complex. If one were to wish to copy pages from one OpenXPS file to another, they would need to create a complete OpenXPS package containing just the required pages plus the required resources from the original OpenXPS package then post the new OpenXPS file to the clipboard. The consuming application would then be able to access that file and its resources reliably and logically insert the pages and resources into their OpenXPS document package as needed. I'm sure this can be and has been already done. > If an application such as an XPS Viewer were to allow selecting and copying of the text or image elements displayed on the screen, that data would be placed on the clipboard as text or whatever image format the application chooses to provide, right. And one day that format might be openXPS. > but posting the markup for the selection to the clipboard would not provide the relevant resource data and hierarchy and would thus be unusable as OpenXPS at that point. no markup only copy. > I believe, then, that it is correct to say that the clipboard format would always be a complete OpenXPS file with .oxps extension. It is the only format for the clipboard that would provide the required interoperability between OpenXPS-consuming applications. I think this is correct. paul
- [ietf-types] Request for review of standards tree… Brian Clubb
- Re: [ietf-types] Request for review of standards … Paul Libbrecht
- Re: [ietf-types] Request for review of standards … Brian Clubb
- Re: [ietf-types] Request for review of standards … Paul Libbrecht
- Re: [ietf-types] Request for review of standards … Brian Clubb
- Re: [ietf-types] Request for review of standards … Paul Libbrecht
- Re: [ietf-types] Request for review of standards … Paul Libbrecht
- Re: [ietf-types] Request for review of standards … Brian Clubb
- Re: [ietf-types] Request for review of standards … Paul Libbrecht
- Re: [ietf-types] Request for review of standards … Brian Clubb
- Re: [ietf-types] Request for review of standards … Brian Clubb
- Re: [ietf-types] Request for review of standards … Paul Libbrecht
- Re: [ietf-types] Request for review of standards … Brian Clubb