[mpeg-OTspec] Re: Proposed mandatory and optional features of the Composite Font format

[Ken Lunde]

Mikhail,

The solution sounds simple to me.

Unknown properties specified by a producer should be allowed, but very  
strongly discouraged. The whole point of this exercise is to develop a  
Composite Font format that will satisfy the needs of producers, and at  
the same time enable consumers to use them in a more consistent  
manner, though as daan pointed out, consistent behavior across clients  
cannot be guaranteed by any format. We have enough people involved in  
this discussion to come up with a complete list of properties for each  
of the primary tags -- <ComponentFont>, <Language>, and <Encoding> (in  
an appropriate namespace, of course) -- so I would be surprised if  
producer has a need for an unknown property. The bottom line is that  
if the property is not in the specification, there is no way for  
specification-compliant consumers to be aware of it, and more  
importantly, how to properly deal with it.

For anything that is documented in the specification, a consumer will  
necessarily be aware of its existence, and a lack of support for a  
particular attribute or property by a given consumer means that they  
explicitly chose not to support it.

Regards...

-- Ken

On 2009/08/05, at 20:58, Mikhail Leonov wrote:

> Hi Ken,
>
>> In other words, consumers will know what the
>> properties mean, and if they choose to ignore them, it is because  
>> they
>> chose to do so.
>
> Not necessarily. I believe we've always wanted to provide room for  
> unknown properties that may be introduced for custom purposes. Is  
> this no longer something you feel necessary?
>
> Best regards,
> Mikhail
>
> ________________________________________
> From: mpeg-OTspec at yahoogroups.com [mpeg-OTspec at yahoogroups.com] on  
> behalf of Ken Lunde [lunde at adobe.com]
> Sent: Wednesday, August 05, 2009 8:02 PM
> To: mpeg-OTspec at yahoogroups.com
> Subject: Re: [mpeg-OTspec] Re: Proposed mandatory and optional  
> features of the Composite Font format
>
> Mikhail,
>
> If we were effecting a change to an existing specification, that is
> one thing, but as I stated a day or two ago, *any* client that
> supports this new Composite Font format will necessarily do real work,
> meaning that their engineers will be required to read its  
> specification.
>
> The format will be documented, and compared to existing Composite Font
> solutions, the specification and resulting documentation will be
> arguably better. In other words, consumers will know what the
> properties mean, and if they choose to ignore them, it is because they
> chose to do so.
>
> Regards...
>
> -- Ken
>
> On 2009/08/05, at 19:52, Mikhail Leonov wrote:
>
>>
>> Daan,
>> through "mandatory unknown" properties creator provides consumers
>> with additional information they may not otherwise have.
>>
>> If a consumer sees property Y it does not understand, how can it
>> decide whether it represents something that is reasonably safe to
>> ignore or something sensitive and important?
>> In other words, how does the rational consumer make decisions you
>> mention in your individual replies? Remember, the consumer doesn't
>> even know what these properties mean.
>>
>> Best regards,
>> Mikhail
>>
>> From: Daniel Strebe [dstrebe at adobe.com]
>> Sent: Wednesday, August 05, 2009 5:01 PM
>> To: Mikhail Leonov; mpeg-OTspec at yahoogroups.com
>> Subject: Re: [mpeg-OTspec] Re: Proposed mandatory and optional
>> features of the Composite Font format
>>
>>
>> Mikhail and colleagues:
>>
>> 1.      A font contains a glyph with the digital signature of an
>> approval manager. The composite font author intent is to create a
>> recipe that will only use this font if the digital signature
>> matches. If the recipe reader is unable to verify the digital
>> signature, the recipe author wants to indicate to all such readers
>> to skip this particular font entry.
>>
>> I do not see this as any different than (3). Why is the creator
>> responsible for the consumer’s decision about whether or not to use
>> a font whose digital signature does not match? The presence of the
>> signature already states the creator’s intent. Marking the signature
>> as a mandatory attribute for reconstructing the composite font is
>> redundant and prone to being ignored by those who do not see any
>> reason to be bound by the creator’s fiat, particularly since the
>> consumer has no way to discern the reason for the fiat. All such a
>> flag does is say, “Trust me on this: You don’t want to use this
>> font unless you can follow all my rules exactly.” To which the
>> consumer replies, “Maybe. Maybe not.”
>>
>> 2.      A font vendor released multiple versions of the same font,
>> and some of the versions contained politically sensitive characters.
>> The composite font author intent is to direct all readers of this
>> particular font version to map specific characters differently if
>> certain font versions are encountered. For consumers that are unable
>> to interpret font versions altogether, the author wants to indicate
>> that particular font entries must be skipped.
>>
>> The creator has expressed its intent in the recipe; that is where
>> its responsibility ends. Whether the politically sensitive glyphs
>> are any concern of the consumer is something only the consumer
>> knows. Consumers within a jurisdiction that has politicized glyphs
>> already know the issues and ultimately are responsible for what they
>> render. Consumers outside those jurisdictions do not care. A
>> jurisdiction is not going to hold a creator responsible for a
>> consumer’s failure.
>>
>> 3.      A font family with the same name was released by multiple
>> manufacturers. The composite font author intent is to create a
>> recipe that will only use the font released from a particular
>> vendor, otherwise the font should not be used. For composite font
>> readers that are unable to extract the manufacturer name, the intent
>> is to err on the side of caution and not to use the font entry.
>>
>> Then the consumer is left with no font. How is that better than a
>> font that may not exactly express the intent of the creator? While
>> the creator may know there are extant fonts of the same name from
>> multiple vendors (or maybe there aren’t, but the creator just wants
>> to mark everything mandatory anyway), how does the creator in any
>> position to know that the differences are relevant to the consumer?
>> Is not erring on the side of caution the prerogative of the consumer?
>>
>> The issue of the minimum valid composite font is also interesting.
>> Given that component fonts may not be present on the target system,
>> it looks like the consumer already has to deal with the situation
>> when a composite font doesn’t cover even a single character. In this
>> case, the mandatory rule 4 doesn’t provide much value, and perhaps
>> we should consider empty composite fonts valid as well.
>>
>> A composite font with no components does not express any useful
>> intent. Does it? The question of whether an element in a composite
>> font recipe should be mandatory has nothing to do with a consumer’s
>> capabilities. It has only to do with expressing the semantics of the
>> intent.
>>
>> Regards,
>>
>> ― daan Strebe
>> Senior Computer Scientist
>> Adobe Systems Incorporated
>>
>>
>> On 09/08/05 16:23, "Mikhail Leonov" <mleonov at microsoft.com> wrote:
>>
>> Daan, Ken, and others,
>> Thanks for your feedback so far!
>>
>> I would like to clarify the purpose of “mandatory unknown”
>> attributes.
>>
>> Unlike “optional unknown” attributes, they are meant to be used by
>> the creator to clarify their intent in specific and sensitive cases.
>> Consider these examples:
>> 1.      A font contains a glyph with the digital signature of an
>> approval manager. The composite font author intent is to create a
>> recipe that will only use this font if the digital signature
>> matches. If the recipe reader is unable to verify the digital
>> signature, the recipe author wants to indicate to all such readers
>> to skip this particular font entry.
>>
>> 2.      A font vendor released multiple versions of the same font,
>> and some of the versions contained politically sensitive characters.
>> The composite font author intent is to direct all readers of this
>> particular font version to map specific characters differently if
>> certain font versions are encountered. For consumers that are unable
>> to interpret font versions altogether, the author wants to indicate
>> that particular font entries must be skipped.
>>
>> 3.      A font family with the same name was released by multiple
>> manufacturers. The composite font author intent is to create a
>> recipe that will only use the font released from a particular
>> vendor, otherwise the font should not be used. For composite font
>> readers that are unable to extract the manufacturer name, the intent
>> is to err on the side of caution and not to use the font entry.
>>
>>
>> In other words, “mandatory unknown” attributes are meant to be more
>> of an exception that a rule. I believe they are a necessary tool for
>> composite font author to indicate very sensitive parts of the
>> recipe. Without ability to flag such attributes, it would be
>> impossible to express all intents carefully.
>>
>> I understand Daan’s concern about overly broad use of “mandatory
>> unknown” attributes, however I don’t believe possible misuse of a
>> capability should lead to the removal of such capability altogether.
>>
>> The issue of the minimum valid composite font is also interesting.
>> Given that component fonts may not be present on the target system,
>> it looks like the consumer already has to deal with the situation
>> when a composite font doesn’t cover even a single character. In this
>> case, the mandatory rule 4 doesn’t provide much value, and perhaps
>> we should consider empty composite fonts valid as well.
>>
>> Please let me know your thoughts on these issues, and best regards,
>> Mikhail Leonov
>> Microsoft
>>
>>
>>
>> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-
>> OTspec at yahoogroups.com] On Behalf Of Ken Lunde
>> Sent: Wednesday, August 05, 2009 1:36 PM
>> To: mpeg-OTspec at yahoogroups.com
>> Subject: [mpeg-OTspec] Re: Proposed mandatory and optional features
>> of the Composite Font format
>>
>>
>>
>> daan,
>>
>> I find myself in complete agreement with you.
>>
>> -- Ken
>>
>> On 2009/08/05, at 11:39, Daniel Strebe wrote:
>>
>>>
>>> Vladimir and colleagues:
>>>
>>> I do not object to parts of the specification being mandatory. In
>>> particular if a consumer cannot even properly parse a recipe then it
>>> has no business calling itself a composite font consumer. My
>>> objection is to providing for a creator to deem portions of its
>>> recipe to be “mandatory”. So far I am unable to invent
>>> scenarios where that is useful or even meaningful.
>>>
>>> With regard to (a) below, I do not see how an incomplete
>>> implementation of a consumer creates incompatibilities. It is the
>>> recipes that must adhere to the specification in order to prevent
>>> incompatibilities. Certainly text laid out by means of
>>> Consumer A’s implementation may not precisely match text laid
>>> out by Consumer B’s implementation because they differed in
>>> their ability to realize the intent of the recipe. But why is that
>>> the concern of this working group? We are not creating a
>>> specification for a page description language and surely we have no
>>> expectation that two different layout engines will yield identical
>>> results when using this composite font format. We do not even expect
>>> that when using OpenType fonts because far too much in layout
>>> depends on considerations external to fonts, let alone that the
>>> OpenType specification itself contains plenty of vagueness.
>>>
>>> I agree with the remainder of Vladimir’s comments.
>>>
>>> To summarize: Mandatory elements of the specification and of
>>> recipes created by it are orthogonal to creator-specified mandatory
>>> elements of a recipe. They should not be discussed together or
>>> confused with each other. I understand and accept mandatory elements
>>> in the specification (but think should be specified with parsimony).
>>> I cannot see any meaning in creator-designated mandatory elements. I
>>> don’t imagine I’ve thought of everything, though, so I
>>> am open to convincing arguments.
>>>
>>> Regards,
>>> ― daan Strebe
>>>
>>>
>>> On 09/08/05 8:11, "Levantovsky, Vladimir" <vladimir.levantovsky at monotypeimaging.com
>> <mailto:vladimir.levantovsky%40monotypeimaging.com>
>>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> Dear Ken, all,
>>>
>>> I suggest that in an attempt to define the mandatory and optional
>>> parts of the Composite Fonts solution we should consider the
>>> following:
>>> a) Given a complete freedom, consumers would likely implement
>>> support for only a limited subset of elements and attributes *they*
>>> consider useful and/or practical, which may cause most of the
>>> composite font implementations be incompatible with each other.
>>> Thus, the definition of mandatory and optional elements of the
>>> Composite Font specification should be viewed as a mean to insure
>>> certain interoperability level(s) between different implementations.
>>>
>>> b) Specifying a set of mandatory and optional elements and
>>> attributes defines the “toolset” that is available for
>>> producers of a Composite Font. It gives them a valuable information
>>> about the tools they can rely on (i.e. mandatory elements and
>>> attributes that are guaranteed to be supported by any
>>> implementation) and the tools that producers may consider using, but
>>> without an explicit guarantee that all implementations would be able
>>> to support them.
>>>
>>> c) It is typical that some levels of granularity may be
>>> necessary to define optional components. The practice that is widely
>>> accepted by many standards organization is to signify support for
>>> different elements and attributes using at least three levels where
>>>
>>> - Mandatory parts are defined using terms MUST (MUST NOT) or
>>> SHALL (SHALL NOT), and define the concepts or tools that have to be
>>> supported unconditionally to insure the required level(s) or
>>> interoperability between different implementations;
>>>
>>> - Recommended parts are defined using terms SHOULD (SHOULD
>>> NOT) and define the concepts or tools that are considered very
>>> useful and even necessary for implementations to support, although
>>> it is recognized that supporting these parts of the spec may place
>>> an additional burden on implementations. The implied meaning
>>> of “SHOULD” in the spec language is that support for a
>>> particular item is strongly recommended but implementations may
>>> choose to not implement for good reason.
>>>
>>> - Optional parts are defined using terms MAY (MAY NOT) and
>>> indicate parts that are truly optional.
>>>
>>> For formal definitions of these terms and their meaning please see
>>> RFC 2119 (http://www.ietf.org/rfc/rfc2119.txt).
>>>
>>> I would like to emphasize it once again that the sole purpose of
>>> specifying mandatory, recommended and optional elements and
>>> attributes is to insure certain level of interoperability between
>>> different consumer implementation, and to enable producers employ a
>>> limited toolset that they can rely on to always be supported by
>>> different implementations.
>>>
>>> I agree with Daan that giving the ability for creators to specify
>>> what elements (and/or attributes) of a particular recipe *they* feel
>>> are mandatory isn’t going to be useful if implementation is
>>> simply incapable of supporting a particular element. However, while
>>> I agree that we as the owners of specification do not have any
>>> practical ability to “enforce” the
>>> “mandatory” parts, it is generally accepted
>>> standardization practice that only those implementations that
>>> support all mandatory parts of the specification may call themselves
>>> compliant. Sometimes, additional conformance requirements are
>>> specified (e.g. as is the case with OFF standard) where multiple
>>> conformance levels can be defined that also include recommended or
>>> optional parts. In this case, a compliant implementation must
>>> implement some optional parts of the spec to be conformant.
>>>
>>> Best regards,
>>> Vladimir
>>>
>>>
>>>
>>> From: mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.com
>>> [mailto:mpeg-
>>> OTspec at yahoogroups.com <mailto:OTspec%40yahoogroups.com> ] On
>> Behalf Of Ken Lunde
>>> Sent: Tuesday, August 04, 2009 1:19 PM
>>> To: mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec 
>>> %40yahoogroups.com
>>>
>>> Subject: Re: [mpeg-OTspec] Proposed mandatory and optional features
>>> of the Composite Font format
>>>
>>>
>>>
>>> daan,
>>>
>>> I will be interested to hear what ideas others have with regard to
>> the
>>> notion of mandatory. In the end, I think that the sole purpose of
>>> mandatory is to describe the conditions under which a Composite Font
>>> cannot function. The format itself can describe some aspects of
>> this,
>>> such as the requirement to include at least one <ComponentFont>
>>> instance, but there may be value in giving some of this power to the
>>> creator. But, I agree that this can become the proverbial rope that
>>> can be used to hang oneself, meaning that it can be abused if not
>> used
>>> wisely.
>>>
>>> Also, while we are on the topic of the format and syntax, one strong
>>> suggestion that I'd like to relay to the AHG is that the XML use a
>>> namespace. This comes from someone else at Adobe, and I second the
>>> recommendation.
>>>
>>> Regards...
>>>
>>> -- Ken
>>>
>>> On 2009/07/30, at 18:39, Daniel Strebe wrote:
>>>
>>>>
>>>>
>>>> Mikhail:
>>>>
>>>> Thank you for the thoughtful proposals. I agree with Ken
>>>> Lunde’s responses (so I will not echo them) with the
>>> exception
>>>> of this matter:
>>>>
>>>> Before drilling into exact syntax of such properties, I would like
>>>> to discuss one particular issue. I believe some of the optional
>>>> properties can be safely ignored by the composite font consumers
>>>> without breaking the intent of the composite font producer, while
>>>> other optional properties should cause the consumers unable to
>> honor
>>>> their semantics to skip containing elements entirely.
>>>>
>>>> I do not think the specification should give creators authority
>> that
>>>> can be so easily thwarted. Many consumers will choose to
>>>> ignore “mandatory” directives because those directives
>>>> do not suit their purposes. Meanwhile providing a mechanism to
>>>> specify mandatory elements will merely encourage “control-
>>>> freak” creators to mark everything in sight
>>>> “mandatory”. Neither we, as the owner of the
>>>> specification, nor the creator, whose intent is expressed by the
>>>> recipe, has any practical ability to “enforce” what is
>>>> called “mandatory”. Should we not stick with the
>>> policy
>>>> that anything stated in the recipe expresses the creator’s
>>>> intent? And that elements absent in the recipe signal no
>> particular
>>>> intent? A mandatory signal is redundant, and redundancies are to
>> be
>>>> avoided, if for no other reason than that a consumer will digest a
>>>> recipe and immediately find itse! lf confused over elements
>> present
>>>> but not marked mandatory. Are the unmarked elements actually
>>>> optional? If so, why are they present?
>>>>
>>>> Instead of a “mandatory” flag, should we not allow the
>>>> producer to rank elements according to how important they are? How
>>>> is “mandatory” versus not mandatory anything more than
>>>> a polarized ranking of “not so important” to
>>>> “critical”? And once we ask that question, can we not
>>>> see that the creator cannot assess the needs of the consumer and
>>>> really ought not to be trying? The creator can state its intent
>>>> already without assigning metrics of gravity to the elements. Its
>>>> own intent is all it knows. The consumer knows how well it can
>> honor
>>>> that intent and is obliged to honor it to the extent that it can.
>>>> Surely no one’s legitimate interests are served by handing
>>>> creators a mechanism for bullying consumers into rejecting what
>>>> might be a perfectly serviceable interpretation of a recipe just
>>>> because the creator suffers delusions of power.
>>>>
>>>> I think we should analyze explicit scenarios that require the
>>>> “mandatory” mechanism before we inject it into the
>>>> specification. I would be very surprised if we found any scenarios
>>>> that really benefit from it.
>>>>
>>>> Regards,
>>>>
>>>> ― daan Strebe
>>>> Senior Computer Scientist
>>>> Adobe Systems Incorporated
>>>>
>>>>
>>>> On 09/07/29 22:42, "Mikhail Leonov" <mleonov at microsoft.com<mailto:mleonov%40microsoft.com
>>> <mailto:mleonov%40microsoft.com
>>>>> wrote:
>>>>
>>>>
>>>> Hi everyone,
>>>> I would like to provide an update on mandatory and optional
>> elements
>>>> in the composite font format.
>>>>
>>>> First, some background. During phone conference meetings that
>>>> preceded the formal creation of this working group, parties
>> involved
>>>> concluded that, due to the diversity of font handling platforms
>> and
>>>> programming interfaces in the industry, it was not practically
>>>> feasible to agree on a single predefined set of composite font
>>>> elements and properties that would express existing font selection
>>>> models and approaches. Instead, it was recommended to give
>> composite
>>>> font producers and consumers flexibility to introduce optional
>>>> properties that wouldn't necessarily be used or even understood by
>>>> all conformant consumers. At the same time, semantics of such
>>>> properties should be defined as clearly as possible, so that an
>>>> implementation that chooses to suport them can do so in a way
>>>> compatible with other consumers and producers.
>>>>
>>>> In addition to such optional properties, there are core pieces of
>>>> the composite font format that conforming implementations must
>>>> interpret correctly to provide the minimum degree of
>>> interoperability.
>>>>
>>>> The purpose of this email is to start creating a list of mandatory
>>>> and optional features in the composite font format.
>>>>
>>>> The format is assumed to be based on the latest composite font
>>>> syntax proposal uploaded to this AHG discussion list by Ken Lunde.
>>>> Since I don't recall us discussing the root element mandated by
>> the
>>>> XML specification, I propose introducing a root element called
>>>> CompositeFont.
>>>>
>>>> Here is a complete composite font file that prescribes the
>> consumer
>>>> to use font "Times New Roman" for all Unicode characters and all
>>>> languages:
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <CompositeFont>
>>>> <ComponentFont Target="Times New Roman"/>
>>>> </CompositeFont>
>>>>
>>>> I propose that a conforming composite font consumer must:
>>>> 1. Recognize and parse basic XML structure as outlined above,
>>>> including the standard XML header and the root element
>>> CompositeFont.
>>>> 2. Reject composite font files that violate the standard XML
>>>> specification.
>>>> 3. Recognize, parse, and interpret all possible valid values for
>> the
>>>> following elements and attributes (these elements and attributes
>> are
>>>> furthermore called mandatory):
>>>> a) ComponentFont element and its Target attribute. The
>>>> interpretation of the Target attribute value is allowed to vary
>>>> between consumers depending on the target environment font
>> grouping
>>>> model. For example, a consumer may be using OpenType Preferred
>>>> names, Win32 names, Postscript names, WWS names, or some other
>> font
>>>> selection model that may not even be OpenType based. However, the
>>>> consumer must use a font model that supports at least one font
>>>> format and assigns name values to font files that conform to
>>>> supported font formats. In addition, the consumer must parse
>> comma-
>>>> separator characters that can be used to separate multiple font
>>>> names inside one Target attribute value, omit leading and trailing
>>>> whitespace characters from font name values, and honor the escape
>>>> sequence that encodes the comma character itself if it appears
>> as a
>>>> part of the font name. I propose double comma ",," as an escape
>>>> mechanism for such cases.
>>>> b) Encoding element and its Target and Original attributes. These
>>>> are described in Ken Lunde's email, and I won't repeat the
>> semantics
>>>> here. Similar to the Target attribute semantics, the
>> interpretation
>>>> of Unicode characters supported by a font may vary depending on
>> the
>>>> target environment font model. For example, a consumer may prefer
>>>> one cmap table format to another. However, the consumer must use a
>>>> font model that provides an ability to obtain Unicode coverage for
>>>> all supported font formats.
>>>> c) Language element and its Target attribute. I would like to
>>>> change the Target attribute values from the original definition
>>>> provided by Ken, which used ISO 639-2/T language codes, to a
>>>> definition that uses IETF language tags, as specified by RFC 4646.
>>>> The key difference is ability to differentiate between multiple
>>>> character sets for the same language, for example Simplified
>> Chinese
>>>> ("zh-Hans") vs. Traditional Chinese ("zh-Hant"). The conforming
>>>> implementation must properly match language tags. There is a
>> couple
>>>> of interesting corner cases here that I would like to discuss in
>>>> more detail - exact rules for matching language tags that are
>>>> related to each other, and handling of empty language tags and
>> cases
>>>> where the language infomation is not available to the font
>> selection
>>>> algorithm.
>>>> 4. Reject composite font files that don't contain at least one
>>>> ComponentFont elements.
>>>> 5. Interpret composite font elements in the order they appear in
>> the
>>>> font file.
>>>>
>>>> In addition to the mandatory elements and attributes described
>>>> above, there is a large group of elements and attributes that are
>>>> considered optional, such as scale, common baseline and height
>>>> metrics, the display name of the composite font itself, font style
>>>> coercion, digital signature enforcement, optical size, required
>> font
>>>> version, font checksum validation, and others.
>>>>
>>>> Before drilling into exact syntax of such properties, I would like
>>>> to discuss one particular issue. I believe some of the optional
>>>> properties can be safely ignored by the composite font consumers
>>>> without breaking the intent of the composite font producer, while
>>>> other optional properties should cause the consumers unable to
>> honor
>>>> their semantics to skip containing elements entirely. An example
>> of
>>>> the former class is handling of Scale attribute of the
>> ComponentFont
>>>> entry on platforms that don't support font scaling. An example of
>>>> the latter class is required font version range. If the consumer
>> is
>>>> unable to extract a version from the font, then it is unable to
>>>> honor the producer intent, and a font entry should arguably be
>>>> skipped altogether. I propose that the composite font format
>> should
>>>> contain provisions that enable consumers to tell whether
>>>> encountering an unknown attribute should cause the element it
>>>> belongs! to to be ignored or not.
>>>>
>>>> Please note that the proposals above are by no means final, and
>> any
>>>> suggestions, corrections and additions are very welcome.
>>>>
>>>> Thanks in advance, and best regards,
>>>> Mikhail Leonov
>>>> Microsoft
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>