cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [cgmo-webcgm] more getObjectExtent questions
- From: "Weidenbrueck, Dieter" <dweidenbrueck@ptc.com>
- To: "Lofton Henderson" <lofton@rockynet.com>,<cgmo-webcgm@lists.oasis-open.org>
- Date: Fri, 13 Jun 2008 12:16:17 -0400
Lofton,
re Question 2:
Both size and style properties should affect the box. If
transform as a transient state affects the box, so should style
properties.
Regards,
Dieter
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]