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] (1)(f) and (1)(g) -- audience and working language

2008/6/12 Sam Johnston <samj@samj.net>:

> I was merely looking for something suitable and usable today.

Exactly. This could be one we need to defer until we can find
a way to test it automatically? I guess we'd need implementer
agreement too if Ricks ideas are to be picked up?
Certainly the main TC.

 You noted:
> Rick Jelliffe suggested a conversion to, say, SVG or xsl-fo
> or something that clearly was position oriented in an xml
> form. Perhaps that's a way ahead for simple text.
> This sounds like a more elegant approach, except that it is the
> application's ability to interpret and render a document (like a browser
> interprets and renders HTML/CSS) that is under the microscope

I don't know, I don't see that as resolved/agreed at all Sam.
I prefer the 'line and character position' idea as more doable
than pixel based. Still a long way from a testable requirement though.

and as such
> this 'new layer' would have to be built into the app, yes? Even without
> native PDF support you can pretty much always extract a PDF/PS printjob from
> the OS, which may indeed be more reliable (one less variable in the PDF
> engine itself).

I can't wait for the first vendor to cry foul when he can't :-)
I don't think we can make such assumptions?

> Anyway this is getting a little OT...

I'm unsure it is off topic. Unless we can see a way to implement
something there seems little point in asking for it?
Whether it's this TC or the following one I'm less sure.
I'd hate to see an unverifiable requirement from this TC. That's
planning for failure.

there appears to be a requirement that
> we examine the ('printed') output of these applications and whether that is
> by a new presentation layer, scraping the GUI, using the built in print
> functions or indeed actually printing is more implementation than policy
> (charter). *What* we expect, in terms of scaling, devices, tolerances etc.
> is more on topic.

Personal view. I can see that being testable so I'd be OK to see that
as a requirement.

-1 to scaling (not in ODF AFAIK????)
devices are a profiling issue.
tolerances I'd be OK to leave to "TC+1" (the people following this TC
to turn our dreams into code?)


Dave Pawson

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