[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, 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] Hello Dieter, Hi Lofton, -----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.
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.
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.
[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]