cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: more getObjectExtent questions
- From: Lofton Henderson <lofton@rockynet.com>
- To: cgmo-webcgm@lists.oasis-open.org
- Date: Fri, 13 Jun 2008 09:52:44 -0600
All --
I don't have enough detail to finish the editing for text size and
getObjectExtent. The minutes said: "Approved: wording of
bottom line to top line and length of the restricted text box or the sum
of width metrics for the text string in the case of a
substring"
The current text in 5.7.6 for gOE() reads: "The bounding box
calculation is based on the abstract locus of the primitives within the
APS. It is not affected by CGM Primitive Attribute (such as line width)
or Control elements, nor by APS Attributes or Style Properties. It is
affected by geometric transform. "
From previous discussion, I think concluded that we do want the size of
the text to affect the extent. Correct? So we probably want
to modify the current wording at least for "...except size of text,
which affects the box as follows..." Which leads to the first
question.
QUESTION 1: How should size of text affect
getObjectExtent?
Discussion: The telecon-resolved "bottom line to top
line" is fine in general. But it leaves some detail
unanswered: BL-to-TL of what? I think we want: BL-to-TL
of the font size that is actually used to render the Restricted Text,
after taking into account all text attributes, the Restricted Text box
height (rt-height), the Restricted Text Type (RTT), etc.
About the latter ... does RTT affect it? The stated motivation for
BL-to-TL is to accommodate possible diacritical marks and descenders
without having to do character-by-character analysis of the string.
So if RTT were boxed-cap, then the contribution of a text element to gOE
would be a little bigger than the rt-height. If the RTT were
boxed-all, then the rt-height itself equals the needed BL-to-TL
distance.
Recommendation: The gOE() extent calculation should use the
BL-to-TL of the effective font size that reflects all text attributes,
the height (rt-height) of the Restricted Text box, and the Restricted
Text Type.
Note that these are still easy computations compared to
stroke-by-stroke. Just more fully specified. Some wording
like the above paragraph would go into gOE().
QUESTION 2: Should the text-size and font Style Properties affect
getObjectExtent()?
Discussion: Should the text-size Style Property have an
effect? I.e., should the gOE() reflect the original WebCGM
contents, or the transiently modified viewed version?
My initial inclination is "no". But I don't feel strongly
and could easily be convinced otherwise. I base "no" on
the principle that text-size (and text-font) SP are transient visual
changes whose main use case is to produce a highlighting or
attention-getting effect.
If you think that the use case for this stuff requires "yes" --
i.e. text related SP do affect gOE() -- please comment.
Recommendation (weak preference): text-related SP do not affect
it.
Conclusion: I don't think the particular resolutions are
critical. We just need a little more detail so that implementors
and users have uniform expectations.
-Lofton.
[1]
http://docs.oasis-open.org/webcgm/v2.1/cd01/WebCGM21-DOM.html#L5095
[2]
At 03:56 PM 6/11/2008 +0000, david.w.cruikshank@boeing.com wrote:
[...]
http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/download.php/28529/20080611_WebCGM_TC_Telecon_minutes.pdf
PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]