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] My perspective. display perferct?


--- On Sat, 7/5/08, jose lorenzo <hozelda@yahoo.com> wrote:

> From: jose lorenzo <hozelda@yahoo.com>
> Subject: Re: [oiic-formation-discuss] My perspective. display perferct?
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Saturday, July 5, 2008, 10:14 AM
> --- On Sat, 7/5/08, Peter Dolding <oiaohm@gmail.com>
> wrote:
> 
> > From: Peter Dolding <oiaohm@gmail.com>
> > Subject: Re: [oiic-formation-discuss] My perspective.
> display perferct?
> > To: hozelda@yahoo.com
> > Cc: oiic-formation-discuss@lists.oasis-open.org
> > Date: Saturday, July 5, 2008, 9:34 AM
> > On Sat, Jul 5, 2008 at 9:30 PM, jose lorenzo
> > <hozelda@yahoo.com> wrote:
> > 
> > > 2 pixels is twice as thick as 1 pixel, ie, 100%
> extra
> > thick. So you can create a series of lines across the
> ...
> > Ok we are nailed right off the start line.  Most parts
> of
> > ODF don't
> > use pixels.   They use relative measurements like cm
> pt
> > inch real
> > world distances.   Simply put for over 90 Percent of
> ODF
> > this is
> > unworkable.   When you are in the world of conversions
> you
> > have to
> > allow for rounding errors on scaling.
> > 
> > Layout Perfect or Typesetting Perfect what every you
> want
> > to call it
> > were there is tolerance for error to a small amount is
> > workable.
> 
> Not all +-2 pixel cases are created equal. There is a
> significant error between the equivalent of .4 pixels
> (rounded down to 0 pixels) and 2.4 pixels (rounded down to
> 2 pixels). Thus a line could be off by a multiple of SIX in
> real measurements yet show up as only 2 pixels during a
> particular rendering. [I'm ignoring -2 for this
> argument, but if anything this likely makes the arg
> stronger.] In fact, it only gets worse here if the correct
> width of the line was to be less than .4 pixels after the
> transformation (vs. the actual 2.4).
> 
> As stated at the top of the original post (but not quoted
> here), I am not being specific to this or any example about
> pixel perfection. Context matters, but I wanted to show
> that, should it become desirable to test near a few pixels
> like a 2 pixel difference, this might be very achievable by
> finding a way to adjusting the scale (eg, through repetition
> in close proximity). We can probably find a way to test 2
> pixels, even perhaps quite easily automatically. Context
> matters.
> 
> As an aside, I don't know if ODF talks about rounding,
> but in some scenarios you may want anything greater than
> 0.0 + delta pixels to round up to 1 pixel. The argument
> being that you don't want the FPU error to mess things
> up, but, otherwise, showing a pixel when something exists
> might be preferable to showing nothing. This might be the
> case for very thin lines intended to exist to separate
> items so that the user can see that something is in fact
> there (for non-graphical cases, pixelization would be much
> less relevant).

I sent this prior email too quickly. The fact is that any such test (as I described in the off by factor of six scenario) would likely have instead been done in other coordinates besides pixels (if ODF tends to use something else as Peter stated). If that test were to pass, there would be no problem of the type I described (the "six" factor issue). In which case, it would be a different test that would test *rendering* being off by 2 pixels, and this 2 pixel range might actually be a useful error range in many cases.

Anyway, IF there is a need to test to within a small number of pixels for some reason (maybe for the assumed 10% of the cases that specify in pixels directly), then consider the example I gave. In fact, the original example was about (iirc) table cell boundaries being off a pixel. In practice, that could have a very noticeable effect for small cells if the error adds on for a large table. If that pixel were to represent an extra 8% to the length of a repeating unit, then the effects could be a bit dramatic or at least noticeably inconsistent across implementations.

Hope I am not clicking too quickly again.




      


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