OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [oiic-formation-discuss] The importance to users of documents looking the same


--- On Wed, 6/18/08, Sam Johnston <samj@samj.net> wrote:

> From: Sam Johnston <samj@samj.net>
> Subject: Re: [oiic-formation-discuss] The importance to users of documents looking the same
> To: robert_weir@us.ibm.com
> Cc: oiic-formation-discuss@lists.oasis-open.org
> Date: Wednesday, June 18, 2008, 12:31 PM
> On Wed, Jun 18, 2008 at 6:17 PM,
> <robert_weir@us.ibm.com> wrote:
> > >
> > "Dave Pawson" <dave.pawson@gmail.com>
> wrote on 06/18/2008 04:33:36 PM:
> >
> > > 2008/6/18 David Gerard <dgerard@gmail.com>:
> > > > (at the risk of bludgeoning the point into
...
> Essentially we will have a scale with raw data editing at
> one end (eg form
> filler that spits out ODF) and typesetting at the other (eg
> pagemaker), with
> most falling in between (OOo, MS Office). The problem is
> that the embedded
> PDF representation will depend on the implementation, so
> taking a beautiful
> document carefully laid out in pagemaker and changing one
> character in OOo
> could cause a train wreck... I think a good way to position
> this feature is
> essentially 'PDF with source code' - if you touch
> it with the same
> implemtentation of the same or greater version then you can
> edit away, but
> if you open it in anohter it might want to save a copy for
> you.

This looks like the problem of extending interop for PDF across apps. To do a thorough job depends on PDF specs.

A "grand unified" standard would be great. That would be quite a task, however. More so if we include stds that have not been mapped usefully to XML.

Isn't Adobe working on XML-izing PDF or something like that? Is someone suggesting we reach out to them? Are we looking at work for this TC?

[Best I know so far..] Simple embedding is something handled by CDRF. One thing ODF would do within that framework (or any similar framework) would be to define the equivalent of an object tag. Then PDF would have to, once in XML form, open up to reveal its DOM.

Actual embedding done in HTML today is opaque and not exactly interoperable wrt the opaque object (eg, two distinct plugins wouldn't necessary behave/render the same any more than two different PDF apps would). To fix that, we'd be working on the PDF interop issue.



      


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]