Re[2]: [cgmo-webcgm] DOM questions and implementation feedback

[TD2d3 <TD2d3@techinfo.mod.uk>]

Title: RE: Re[2]: [cgmo-webcgm] DOM questions and implementation feedbac k

All,

 

First: I would not encourage the placement of text in a graphic, short single callouts, a number etc is fine.

 

Second: Font case changes should not be allowed by users,

 

-However size and color changes would/could promote greater screen readability (Option 2) using setStyleAttr?,

-Possibly in an unusal display environment with tailoring for Human facts?  Surely current tools to zoom and pan over areas for users are fine and many give us some of the functionality.  I am trying to come up with use cases?

 

Regards

Andrew

 

Andrew Moorhouse
CTS TD Graphics Policy and Advice, MoD UK
++44 141 224 2557, fax ++44 141 224 2142
td2d3@techinfo.mod.uk

 

-----Original Message-----
From: DULUC Franck [mailto:franck.duluc@airbus.com]
Sent: 27 August 2004 12:43
To: 'CGM Open WebCGM TC'
Subject: RE: Re[2]: [cgmo-webcgm] DOM questions and implementation feedbac k

Dieter and all,

 

    Your sample is for the user the best cases they are facing: the restricted bounding box is well-defined and exactly matching the text, but it is not alwys like that ;-)

 

    You are right there are two cases : font changes and size changes; the most hazardous is for sure the font change use cases. Nevertheless, I think the complete user requirements (Dave? Andrew?, ...) is "being able to control this kind of effect" (that is what I propose with my boolean parameter).

 

    As a conclusion (for me), I will let the decision in the hand of my vendors and implementors that are at the end the people doing the work. Personnaly I will not encourage the use of such a feature, even if I understand the use cases; indeed I consider and try to promote that the readability on computer screen has to be considered when drawing (and therefore forgetting the paper publishing paradigm). Besides, many tools are implementing bird eyes and magnification that allows correct text reading for the user.

 

Regards,

 

Franck DULUC

-----Message d'origine-----
De : Dieter Weidenbrueck [mailto:dieter@itedo.com]
Envoyé : vendredi 27 août 2004 12:15
À : DULUC Franck; 'CGM Open WebCGM TC'
Objet : RE: Re[2]: [cgmo-webcgm] DOM questions and implementation feedbac k

Hi Franck,

 

I see what you want to accomplish, probably we should separate the two cases here:

 

1. Font change

It may make sense to restrict the size of the text to the original restricted text box here.

I am not sure whether the effect would be very dramatic if we wouldn't do this though.

 

2. Size change

Please consider this text element, the restricted text box is shown.

Option 1:

Change character height, but maintain box intact

Effect: nothing. The height change would be performed, and

afterwards the text element would be refitted into the box

Benoit: There are no overlapping characters in this case, because the

text is measured as a whole.

So the simple effect is that nothing happens.

 

Option 2:

Change character height, forget about box

This will give you the desired effect.

 

BTW, reducing the font size shows a similar behavior

 

Regards,

Dieter

-----Original Message-----
From: DULUC Franck [mailto:franck.duluc@airbus.com]
Sent: Friday, August 27, 2004 11:57 AM
To: 'CGM Open WebCGM TC'
Subject: RE: Re[2]: [cgmo-webcgm] DOM questions and implementation feedbac k

Ok for the use case: I did not think to that. It is true that a user may want intentionally to temporarily increase the size of a text to be able reading it (when the mouse is on for instance). But I think the choice has to be let to the application to override the bounding box when changing the font and/or font-size (our discussion is for both cases I think).

Then I suggest the overriding of the restricted box can be controlled by the user. Looking at the DOM more carefully and especially to setStyleAttr, I then asked myself how to do it as set StyleAttr is a generic function used for multi-purpose, therefore the adding of such parameter is not as esay as its saying.

Regards,

Franck

-----Message d'origine-----
De : Dieter Weidenbrueck [mailto:dieter@itedo.com]
Envoyé : vendredi 27 août 2004 11:40
À : DULUC Franck
Objet : RE: Re[2]: [cgmo-webcgm] DOM questions and implementation feedbac k

All,

I think we have to consider the purpose of this function, which is to increase readability on a computer screen.

The intention is to display an illustration that has been prepared for printout using Times 8pt on screen using
Helvetica 10pt.

On the other side, let's look at the purpose for a restricted text box.
Usually a text is positioned and sized by an authoring tool. Alignment etc is set as well.
So all the details of the text are fully described in the CGM.
As an additional security and help for the recipient of the file, there is the restricted text
box. It is draw tightly around the text.
So the recipient opens the file, sets all text parameters, and then checks the restricted text
box. In most cases, no or minor adjustments have to be made these days.

Now after having read the file (and displayed) I see no more reason to constrain the
text size to the box. In fact, you could increase the character height without changing the display:
the box would basically "undo" the height change.
To achieve the effect described at the top we must override the effect of the restricted text box
in my opinion.
Technical solution:
A text element is in a well-defined state after reading the CGM. Take this state and apply the
character-height change to the character height found in this state.

Regards,
Dieter
-----Original Message-----
From: DULUC Franck [mailto:franck.duluc@airbus.com]
Sent: Friday, August 27, 2004 11:02 AM
To: CGM Open WebCGM TC
Subject: RE: Re[2]: [cgmo-webcgm] DOM questions and implementation feedbac k

Still listening to you guys !!!
BB>>>   3) Since WebCGM only allows for restricted text elements, what is
BB>>>   the usefulness of changing the font-size? ie, it can't exceed the
BB>>>   box height?!
CDW>> This is a question that occurred to me when we initially
CDW>> talked about it in the Cleveland meeting.  Dieter was the one
CDW>> that introduced the change of font size.  I think the restricted
CDW>> text box ends up getting  in the same was as the character height
CDW>> does??
BBAGAIN> It would be good to hear what others think on this one?  The spec will
BBAGAIN>have to be very clear here.  Some options could be:
BBAGAIN> 1) Increase RTEXT BBox by percentage (but how to you place the new
BBAGAIN> box).
BBAGAIN> 2) Increase glyph size once layout algorithm is done based on original
BBAGAIN> values (but the glyphs would overlap)
BBAGAIN> 3) Determine text baseline according to original values, but compute
BBAGAIN> text layout based on new values (I think this one will give the best
BBAGAIN> result, but not sure.)
I am not the expert, but as a user I am too often facing issues with overlapping text that I will ot be in favour of any modification of the restricted text box, as it may affect the readability of the graphic. For me the correct behaviour is to increment the font size as requested and then compute text layout in the bounding box. I think it is your option 3. >From a user point of view it is the safe way, and if the dummy user want a font increase that is not complying with the restricted box this will be his fault and only his. Maybe you can envision that your option 1 may be accessible through a user specification (like a boolean parameter to the function), but I am not sure the benefit will worth the effort to specify and implement correctly this feature.

Best Regards, 

Franck DULUC
Technical Data Research Manager
Customer Services - SDND
AIRBUS France
Phone: +33 (0)5 61 18 19 16
Fax: +33 (0)5 61 93 59 44
mailto:franck.duluc@airbus.com
Address:
BP D0611, 316, route de Bayonne
31060 TOULOUSE Cedex, FRANCE