UPD Mail Archive: UPD> dependencies for composite features

UPD> dependencies for composite features

From: NorbertSchade@oaktech.com
Date: Mon Sep 16 2002 - 14:36:34 EDT

  • Next message: Norbert Schade: "UPD> Copyright for UPDF device description"

    There is another discussion going on:
    How shall a driver behave when it comes to dependencies for composite

    Two weeks ago I was coming from a position that a composite feature is a
    feature as any other. So it may as well have its own dependencies. The
    'old' ones referring to basic features used as components are to be
    I'm not that sure any more.
    Basically most of the old ones would have to be redefined while just
    replacing the condition. May be even the same warning messages are used. If
    not, a new localization effort is necessary.
    In the meantime I'm leaning towards 'use what you have'. It's there. If it
    can be used, no extra effort is necessary.
    Once creating messages be a bit careful with the wording as they may pop up
    with composite features later.
    So there will not be any new localization.
    To be clear: If the composite feature needs something special, go ahead and
    create a new dependency.

    If !simplex, don't use media type transparency.
    Assume we have that dependency for the two basic features and we have a
    composite feature 'Media' with media size and type as components.
    If long-edge is selected and the user tries to select a ComponentSet, which
    involves transparency, the original dependency should pop up.

    I understand that people can have different opinions on this, but we'd like
    to recommend an expected behavior for UPDF drivers in the spec.
    So let's hear some opinions and see, if we can agree.


    This archive was generated by hypermail 2b29 : Mon Sep 16 2002 - 14:37:10 EDT