Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Received-SPF: pass (athena.apache.org: domain of kellypmk@gmail.com designates
 209.85.220.52 as permitted sender)
From: Peter Kelly <kellypmk@gmail.com>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_92896AEE-C98A-4C9B-8593-F088591B714E";
 protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <C3F0C569-7634-46EF-9714-D0529ED1AE79@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: OOXML
Date: Sun, 3 Aug 2014 18:40:22 +0700
References: <20140801084237.fd8a9b8ca6261554f2f0b9b0@iol.ie>
 <22A06F0C-16C5-4640-9C75-9CE8CE66AC17@gmail.com>
 <CAMK9kThZ0WerF=wS4am9XSz2sFqp++FY9zS0FFa09CWT1oT0zQ@mail.gmail.com>
 <79FD7F45-99B8-44A6-B390-5048EC1BDF46@gmail.com>
 <004c01cfae8d$0f4d4e20$2de7ea60$@acm.org>
To: dev@openoffice.apache.org
In-Reply-To: <004c01cfae8d$0f4d4e20$2de7ea60$@acm.org>

--Apple-Mail=_92896AEE-C98A-4C9B-8593-F088591B714E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_211485E2-04E3-4C3A-9C95-63C3E8D4A3DA"


--Apple-Mail=_211485E2-04E3-4C3A-9C95-63C3E8D4A3DA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 3 Aug 2014, at 3:05 am, Dennis E. Hamilton <dennis.hamilton@acm.org> =
wrote:

> In line with the sketch that Peter Kelley provides below, I am =
personally very sympathetic to the idea of having an internal model that =
can tolerate difference in format between input and output while =
preserving in the output everything from the input format it can, even =
by leaving markers that will be useful on future input of the produced =
form.  (There is a well-known case of Microsoft Office doing this for =
HTML it exports, although the added information for recovery of the MSO =
rendition led to many complaints about document bloat.)

On a semi-related note, there's once quite fascinating implementation of =
ODF I've seen called WebODF (see http://webodf.org; the code is open =
source). This is an in-browser editor, and actually works by loading the =
content.xml file from the ODF package into the DOM tree of the browser, =
thus having it contained within the HTML content of the page. Through =
clever use of CSS namespaces, it's able to achieve a pretty faithful =
rendering of the document using the browser's built-in layout engine, =
even though the content itself is not in HTML.

=46rom what I understand about their approach, the reason they did this =
I believe is as a way to ensure that the XML structure of the ODF file =
is preserved exactly, which is much more difficult to achieve if the =
content is converted into HTML first (as in my implementation). Web =
browsers are actually very good at handling content in this way, since =
you can just use the CSS property setting "display: none" to hide any =
elements that shouldn't be rendered on screen, and this CSS can be kept =
entirely separate (or even dynamically generated by javascript) and not =
part of the XML content itself. So WebODF takes advantage of the fact =
that a web browser will just preserve information by default, and it =
works quite well.

--
Dr. Peter M. Kelly
Founder, UX Productivity
peter@uxproductivity.com
http://www.uxproductivity.com/
http://www.kellypmk.net/

PGP key: http://www.kellypmk.net/pgp-key
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)


--Apple-Mail=_211485E2-04E3-4C3A-9C95-63C3E8D4A3DA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On 3 =
Aug 2014, at 3:05 am, Dennis E. Hamilton &lt;<a =
href=3D"mailto:dennis.hamilton@acm.org">dennis.hamilton@acm.org</a>&gt; =
wrote:<br><div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">In line with the sketch that Peter Kelley provides below, =
I am personally very sympathetic to the idea of having an internal model =
that can tolerate difference in format between input and output while =
preserving in the output everything from the input format it can, even =
by leaving markers that will be useful on future input of the produced =
form. &nbsp;(There is a well-known case of Microsoft Office doing this =
for HTML it exports, although the added information for recovery of the =
MSO rendition led to many complaints about document =
bloat.)<br></blockquote><div><br></div><div>On a semi-related note, =
there's once quite fascinating implementation of ODF I've seen called =
WebODF (see&nbsp;<a href=3D"http://webodf.org">http://webodf.org</a>; =
the code is open source). This is an in-browser editor, and actually =
works by loading the content.xml file from the ODF package into the DOM =
tree of the browser, thus having it contained within the HTML content of =
the page. Through clever use of CSS namespaces, it's able to achieve a =
pretty faithful rendering of the document using the browser's built-in =
layout engine, even though the content itself is not in =
HTML.</div><div><br></div><div>=46rom what I understand about their =
approach, the reason they did this I believe is as a way to ensure that =
the XML structure of the ODF file is preserved exactly, which is much =
more difficult to achieve if the content is converted into HTML first =
(as in my implementation). Web browsers are actually very good at =
handling content in this way, since you can just use the CSS property =
setting "display: none" to hide any elements that shouldn't be rendered =
on screen, and this CSS can be kept entirely separate (or even =
dynamically generated by javascript) and not part of the XML content =
itself. So WebODF takes advantage of the fact that a web browser will =
just preserve information by default, and it works quite =
well.</div><div><br></div></div><div><div style=3D"orphans: 2; =
text-align: -webkit-auto; widows: 2; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px;"><div style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div><div><div apple-content-edited=3D"true">--<br>Dr.=
 Peter M. Kelly</div><div apple-content-edited=3D"true">Founder, UX =
Productivity</div><div apple-content-edited=3D"true"><a =
href=3D"mailto:peter@uxproductivity.com">peter@uxproductivity.com</a><br>h=
ttp://www.uxproductivity.com/</div></div><div =
apple-content-edited=3D"true"><a =
href=3D"http://www.kellypmk.net/">http://www.kellypmk.net/</a></div></div>=
<div apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">PGP key:&nbsp;<a =
href=3D"http://www.kellypmk.net/pgp-key">http://www.kellypmk.net/pgp-key</=
a></div><div apple-content-edited=3D"true">(fingerprint&nbsp;5435 6718 =
59F0 DD1F BFA0 5E46 2523 BAA1 44AE =
2966)</div><div><br></div></div></span></div></div></body></html>=

--Apple-Mail=_211485E2-04E3-4C3A-9C95-63C3E8D4A3DA--

--Apple-Mail=_92896AEE-C98A-4C9B-8593-F088591B714E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJT3h+mAAoJECDy9NkmdeTTMWYP/2c/3NpJmuPyqM5DPcSCvlup
Nk8Fb4rOorPF3emcXa70rcsJvo9LiaP3/CbKhDG6jlpUPQHwI6fmVlW16MEQS9bf
c/30oi1XqCDRolWVj3Y63W8Seg1NmCEgq89C1/lfavz945LzXRcFV2qxxb+oiTRk
cFE1noC4lyDt9Hxzqixg70GDLwYsry9LDGeViwzzAGrZMjwi+SJ6ZpYbEK7jzGv5
DXSUuPoXNGckXou/VMrTiysnxOVgAC98PZMey7tqoYqdJ8D7ApB3sYQFveCkOGFQ
FbTpmDIuNR7B67xq1TJx/3ZCiWT/9wmjOkobbHnIgmV7GWAU9+9MGVHh41V9FlD7
ulY4jb+Mkk/pviDx+aBn8/lqOxBORjFGUcSs35c55UZRxL4koKQh9gT5HbUn+R6G
0TjM5z4HpnLuptE8lOncVj7axA13GlwtvYj3wqM6Obxgs6tdd+loEOM9p3NplXub
9jDqguJrQg19j+QelGoPLnLRBLzWjHvdm/oWIhjzXqMV3aqeXrMrPjBj7FMyJWzs
CwmSaMy/ksvGlPJNMEg/dhSKGH7tv3dfQcIRM84G8U7kK5VvVvn+e45aXDRbTGfK
hyzojLIfgNCR3xQfnQQ6+KlrBu/DmGSTitx6/7vwPUpsliFF0wYGXA2LvK8FnpPs
ahYKRFy5LmiJLsrwRl8Z
=0PVM
-----END PGP SIGNATURE-----

--Apple-Mail=_92896AEE-C98A-4C9B-8593-F088591B714E--