OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

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


Subject: RE: [cgmo-webcgm] Action Item: PROPOSAL: setStyleProperty - text-font


All,
 
I can see the benefit in Forrest's proposal, however, this would introduce a kind of search and replace functionality or a conditional styling.
We are not doing this elsewhere, and it would open a whole discussion on variants like
 
setStyleProperty(stroke-width, oldWidth, newWidth)
 
Although all this is useful functionality, I would like to postpone this extension to 2.1.
 
We seem to have to issues now:
 
1. Reliability of font mapping incl. error handling
The assumption is that font usage inside a CGM is safe and bullet-proof right now, where in fact it is not.
Example:
a text element inside a CGM uses a font named "Sushi_23", and contains text elements with UTF-16 encoded
japanese characters. Font properties are stored as well.
This file is viewed on a western PC, no east-asian languages installed. Zero chance that the display will be correct.
 
any text display (at least outside of Adobe13) bears the risk of a missing font, no matter whether the font is
specified inside or outside the CGM.
As Dave pointed out, there is a long (and heavily used) tradition of external font-mapping in CGM, which is now
going to be standardized up to a certain point.
 
I want to reiterate my proposal: Apply the font if it fits, otherwise don't change anything
 
2. Conditional styling
Brilliant idea, almost as brilliant as search and replace on text content, which should be done as well at some
point in time. However, right now, we are only setting properties unconditionally.
Therefore I propose to postpone this discussion for now, and then discuss conditional styling within the scope
of 2.1
 
Regards,
Dieter
 
-----Original Message-----
From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
Sent: Sunday, June 26, 2005 11:53 PM
To: Forrest Carpenter; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Action Item: PROPOSAL: setStyleProperty - text-font

I tend to agree with Forrest.  The use cases that are mentioned at http://lists.oasis-open.org/archives/cgmo-webcgm/200505/msg00091.html are primarily are intended to do font mapping, which has been accomplished with external font mapping tables in the past.
 
I'm not sure I understand the 3 parameters Forrest specifies, but I would think an "old font", "new font" would suffice.  I'm not sure what the "substitute font" is?
 
I also get confused about what the implemention would do when the font replacement is done to a para APS containing mulitple fonts and potentially multiple character sets with notfinal and appendtext strings mixed in.  It seems to me that if you specify which fonts you want to substitute with which ones would clarify the behavior.  I agree that this would add DOM calls and may be contributing to our requiements creep.
 
thx...Dave
-----Original Message-----
From: Forrest Carpenter [mailto:forrest@sdicgm.com]
Sent: Wednesday, June 22, 2005 12:20 PM
To: cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Action Item: PROPOSAL: setStyleProperty - text-font

All,

 

My thoughts on StyleProperty – text-font

 

The major use case for this is to have a standardized method of mapping non-standard or non-existing fonts to fonts that are available on the system. I think a better approach would be to use something like setStyleProperty( substitute-font, old_font, new_font).  This would require a new interface to the WebCGMMetafile (font_list).

 

Comment on: [DW] I am not aware that anybody bundles fonts with a viewer these days

Because we use mostly the same code for UNIX and Windows we bundle the 35 Adobe fonts and the 16 Hershey fonts with our applications.

 

Regards,

Forrest


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Wednesday, June 22, 2005 11:56 AM
To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Action Item: PROPOSAL: setStyleProperty - text-font

 

Hello Dieter,

A couple of replies are embedded...

At 11:10 PM 6/21/2005 +0200, Dieter  Weidenbrück wrote:

Hi Lofton,
 
please find my comments inline.

-----Original Message-----

From: Lofton Henderson [mailto:lofton@rockynet.com]

Sent: Tuesday, June 21, 2005 8:31 PM

To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org

Subject: RE: [cgmo-webcgm] Action Item: PROPOSAL: setStyleProperty - text-font

Dieter,

I do understand the proposed algorithm for text-font.  According to your proposed algorithm, one of two things will happen: 

A.) either you'll get the font you asked for in the text-font Style Property;

[DW] yes

B.) or, you'll get "no change", i.e., what was asked for in the WebCGM instance (Adobe13, or "other+FontProperties"). 

[DW] yes

In the context of technical graphics requirements, this is already much better than the CSS font-matching, which can lead to a wide range of results.

[DW] agreed.

But ... I'm still unconvinced that the introduction of potential variability in the behavior of graphical text is worth the use cases [1] that are gained by introducing the text-font SP, with no font restrictions, and allowing it in WebCGM 2.0's  cgm+xcf  content packages.

[1] http://lists.oasis-open.org/archives/cgmo-webcgm/200505/msg00091.html

Back to my example case (below).  As you pointed out, there was one flawed assumption in my example.  So I'll separate two scenarios.

1.)  behavior on different platforms:  e.g., WinXP, linux, mac, ...  The requested font (e.g., lucidaConsole) may be routinely available on one, but not on another.  So two different systems on Dave's desktop, each running an appropriate version of the same vendor's CGM viewer, might give different results.  Correct?

[DW] How is that different from using any Adobe13 font on any platform, if the font is not installed?

You don't even have to look at different platforms, just look at two computers running XP, one has the font installed, the other one not.

I don't see a problem that you get different results in these cases.



Ah, but WebCGM PPF:
a.) limits valid fonts in CGM instances to Adobe13 (ignoring other+FontProperties for now),
b.) and, requires any conforming viewer to support the Adobe13

These requirements are independent of whether Adobe13 is installed or not.  So according to WebCGM conformance requirements, the result is completely predictable if the author limits fonts used to Adobe13, and it is a conforming viewer. 

Qualification:  "support the Adobe13" is defined in the PPF as:  visually similar (serif, posture, weight, etc), and glyphs placed according to the "Adobe13" font metrics in the tables of CGM:1999 Annex I.

Our viewer had a simple software text generator that could "support the Adobe13", in that qualified sense.  (Indeed, I suspect it would be real hard to pass the ATA test suite without a software text generator, because of the exercising of PATH, ORIENTATION vectors, etc.)

2.)  different viewers on same platform:  I guess I was implicitly thinking, here, of some past experience where the graphic system (e.g., CGM viewer) shipped some font resources as part of the system (e.g., for software text simulation).  That probably is not nearly as common nowadays as using the font resources on the system, which tend to be prodigious.

[DW] I am not aware that anybody bundles fonts with a viewer these days.



The fonts bundled in the HSI viewer(s) were simple, but adequate to pass the text/font conformance requirements of ATA, MP, etc.  (Hence to pass WebCGM 1.0 requirements).

So to summarize my concern ... we're potentially introducing some text unpredictability, and I'm not yet convinced that's a good idea.  As the august graphics experts Weidenbrueck & Henderson wrote [2] about WebCGM (compared to SVG), "Predictability of text model  --  completely constrained and predictable -- ..."

[2] http://www.cgmopen.org/technical/webcgm_svg.htm#S3.3

[Btw, another issue to resolve if we were to include text-font SP:  unless a text-font SP that replaces the font in the CGM is chosen *very* carefully, it will not likely work well with the text restriction box of the RESTRICTED TEXT elements.  How would we address this? ]

[DW] Since we change the font, there will be changes in height and run width. We can discuss the preferred way to go.

[DW] A font size change via style properties will also extend the text beyond the restricting box.



Observation:  starting to mess with the text restriction box requires, in some cases, some intimate knowledge of the author's intent.

I think I'll stop for now.  Respecting your interesting use cases, I still have reservations about the cost-benefit balance (which reservations I don't have for simple things like stroke-color, to fulfill a transient highlighting/emphasis need.)

Cheers,
-Lofton.

[DW] In general you try the accomplish something that may not be possible. We are providing interfaces now to allow for content manipulation, which means to me that we offload some of the responsibilities to the content preparer. CSS, HTML, SVG DOM are all cases where fonts can be specified (among numerous other things that could break), they all have to live with the situation that a resource may not be found.

 

Another example:

Take a WebCGM 1.0 file with symbols. On one computer it will work, because the symbol CGM file is there, on the next one it won't, because the symbols can not be found. Unpredictable in the same way, even with "real" CGM content.

 

With the advent of the DOM, a programmer could potentially do quite a few silly things to the CGM that could break everything, for example setting a line weight that is ridiculous, e.g. 100000 mm wide. He could potentially include text in attributes that is not allowed in the context of the CGM file (think about an ISO Latin 1 file, no UNICODE in the file, but then an attribute is set using Japanese characters). All this requires the viewers to be tolerant, but also that the programmer considers the responsibilities that he has when doing his job.

 

Regards,

Dieter

 

At 06:18 PM 6/20/2005 +0200, Dieter  Weidenbrück wrote:

Lofton,

 

I am not sure whether I understand your concern:

-----Original Message-----

From: Lofton Henderson [mailto:lofton@rockynet.com]

Sent: Monday, June 20, 2005 5:42 PM

To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org

Subject: Re: [cgmo-webcgm] Action Item: PROPOSAL: setStyleProperty - text-font

I'm uncomfortable with one aspect of this proposal:  two different applications processing the same WebCGM 2.0 content could mysteriously get very different results.  This is not supposed to happen in WebCGM.  For example, let's suppose this link occurs in a HTML + WebCGM parts list application:

<a href="pump.cgm#xcf(pump-styles.xml)">Pump subassembly</a>

and the XCF contains:

<webcgm ... text-font="Lofton_Calligraphic" >

[DW] following my proposal, the application would do the following (in pseudo-code):

if "Lofton_Calligraphic" is available then

    for each text element in the selected APS

        if "Lofton_Calligraphic" contains all glyphs needed to represent the text

            set text font to "Lofton_Calligraphic"

    end for

end if

As I assume that the font does not exist, the first check would fail, and hence the application

would not do anything.

If a font with that name really exists, the next test would detect whether it covers the glyphs

needed for the text elements. If this is not the case, nothing will happen either.

I do not understand how two different applications would come to different results other than

if they run in two different environments, one with this font installed, and the other one without?

Please let me know if I am missing anything.

Regards,

Dieter




 

I know that it is not part of Dieter's design intent, but this in fact provides a loophole to completely evade the tight text restrictions and highly predictable graphical text results of WebCGM 1.0.

I am not yet convinced that this is a wise thing to do.

-Lofton.

At 12:28 PM 6/20/2005 +0200, Dieter  Weidenbrück wrote:

All,

here is my proposal regarding the text-font style property:

"text-font: The text-font style property redefines the text font that is used for drawing graphical text within the APS to which it is applied. Text-font corresponds to the font set inside a CGM using the FONT LIST and TEXT FONT INDEX elements. The required behavior is as follows: the application needs to check first whether the specified font resource exists. If so, it has to further ensure that all glyphs of the text it will be applied to exist in that font. If both checks are successful, the application shall apply the font to the text. In all other cases the text remains unchanged."

Comment: I wanted to specify a simply yet clear way for a successful font change. By restricting it to the cases where the font is installed and appropriate I think this can be accomplished.

Regards,

Dieter

 



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