[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: WebCGM preview
Dieter, Preliminary request #1: could you please redo your first table so that it reflects the current Second Release text? You continue to send versions that reflect the original 1/99 text. The current 2nd release text represents what we have discussed and agreed since initial publication, and I consider that it is the only defensible basis for discussing further change. Preliminary request #2: would it be possible to send your two html tables as attachments instead of embedded (or in addition to embedded)? In that way, we could edit comments into the table for discussion. The embedded tables also cause some difficulties for my mailer (I can read them, but they flatten upon "reply", etc). I'll make a couple of comments, and will refer to your table by row (1-4) and column (1-4). But ... I think that this is getting to the point where we cannot resolve it by email. I think a conference call is going to be required. I won't be able to do such until next week (mid-late week) at earliest. At 08:14 PM 5/30/01 +0200, Dieter Weidenbrueck wrote: >[...] >I hate to come up with major changes at this point, it just shows that I >should have thought about it earlier. So here is another table proposing >the minimal changes that make sense. I am apparently missing something. I don't understand your claim "minimal changes that make sense". R1/C1: I don't have a problem with your recommendation. I think it was intended, but an oversight. It is sensible, what one would expect, and doesn't contradict anything else. R2/C1: The spec already says this, but not precisely. It doesn't say "highlight", it says "indicate visually...". The intention is plain, but it could be said better. R4/C1: The current (2nd rel) spec specifically says "no zoom", contrary to your Table 1. R3/C1: For consistency with previous, we recently generated a "no zoom" editing directive for this case (the region replaces the geometry for picking purposes -- i.e., object identification purposes -- it is not in my view a surrogate view context) >We definitely need to apply changes to make 3.2.1.1. and 3.1.2.4. >consistent, one way or the other. You're losing me here. I don't see how your new "zoom" prescription of R3/C1, R3/C2, R4/C1, and R4/C2 are required for "consistency". I see no contradiction if they remain "no zoom", as they currently are, and as has been discussed and decided. Perhaps I'm missing some statement. Can you point me to two phrases that contradict each other in the current 2nd Release text? I.e., something that can be implemented because it says "do A" in one place and "do B" in another place? > >As far as IsoView is concerned I can still change the implementation to >whatever comes out of this discussion. I can go either way without >problem. However, I see Harry's good comments, and I know that some of the >current definitions will at least disappoint users. > My preliminary survey of implementators: 3 do no-zoom on the questionable cases; 1 does zoom; 1 hasn't responded yet; (also I asked Greg at micrografx -- no response yet). Regards, -Lofton.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC