Typo in ICCCM for PIXMAP type? - Xwindows

This is a discussion on Typo in ICCCM for PIXMAP type? - Xwindows ; In section 2.6.2 Target Atoms there is a footnote #7 for the PIXMAP type. See http://tronche.com/gui/x/icccm/sec-2.html . When I click on it it reads: 7. This definition is ambiguous, as the selection may be converted into any of several targets ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Typo in ICCCM for PIXMAP type?

  1. Typo in ICCCM for PIXMAP type?

    In section 2.6.2 Target Atoms there is a footnote #7 for the PIXMAP type.
    See http://tronche.com/gui/x/icccm/sec-2.html. When I click on it it reads:

    7. This definition is ambiguous, as the selection may be converted into any
    of several targets which may return differing amounts of data. The
    requestor has no way of knowing which, if any, of these targets corresponds
    to the result of LENGTH. Clients are advised that no guarantees can be made
    about the result of a conversion to LENGTH; its use is thus deprecated.

    I assume the footnote is referring to the LENGTH type and not the PIXMAP
    type but could someone confirm this please?

    Thanks in advance,
    Charlie


  2. Re: Typo in ICCCM for PIXMAP type?

    CharlieB wrote:
    >In section 2.6.2 Target Atoms there is a footnote #7 for the PIXMAP type.
    >See http://tronche.com/gui/x/icccm/sec-2.html. When I click on it it reads:
    >
    >7. This definition is ambiguous, as the selection may be converted into any
    >of several targets which may return differing amounts of data. The
    >requestor has no way of knowing which, if any, of these targets corresponds
    >to the result of LENGTH. Clients are advised that no guarantees can be made
    >about the result of a conversion to LENGTH; its use is thus deprecated.
    >
    >I assume the footnote is referring to the LENGTH type and not the PIXMAP
    >type but could someone confirm this please?
    >
    >Thanks in advance,
    >Charlie


    Yes, several of the footnotes are misnumbered in that table.

    The problem cited is that STRING, TEXT, UTF8_STRING, COMPOUND_TEXT,
    etc are all potential conversion targets with different resulting
    lengths, so the LENGTH target is ill-defined. That being said, a
    client requesting LENGTH probably knows nothing about i18n, so it
    would make sense to return the length of the STRING target.


+ Reply to Thread