Used synchronise script to update files

1 files changed, 37 insertions, 37 deletions

diff --git a/libxcb/doc/xkb_issues b/libxcb/doc/xkb_issues
index f10c015e5..80efcc1fc 100644
--- a/libxcb/doc/xkb_issues
+++ b/libxcb/doc/xkb_issues
@@ -1,38 +1,38 @@
-

-There are a number of problematic special cases in XKB. The issues 

-mentioned here are at most partly resolved.

- 

-1. The are several XxxDoodad structures defined in xkb.xml. They are used

-   in a few lists, but in a rather special way: 

-   The struct "CommonDoodad" is supposed to be a rather generic data type, 

-   combining the most basic Doodad fields that are common in all these structures. 

-   All Doodads are encapsulated in a union type simply called "Doodad". 

-   Now this union is used in subsequent list definitions, aiming at a kind of 

-   'polymorphism': From inspection of the protocol and Xlib, the Doodads are to 

-   be discriminated based on their type field.

-   However the special meaning of the type field is not encoded in the protocol. 

-   Furthermore the TextDoodad and the LogoDoodad are variable size types due to

-   some fields of type CountedString16, thereby turning the union into a 

-   possibly variable size type as well. 

-   However, for lists with variable size elements, special sizeof functions are 

-   required. These cannot be autogenerated as it cannot be referred which 

-   Doodad type to use for the union. 

-   Therefore, the Doodad type structures are unsupported at the moment. 

-

-2. There are still some bugs in xkb.xml: Either certain fields are missing

-   that are required by the protocol, or Xlib simply has another understanding

-   of the protocol. 

-

-3. The interface for accessors should be reviewed. 

-

-4. Currently some bitcases carry 'name' attributes. These could be avoided if 

-   the data within would consist of a singe struct field only. 

-

-5. switch could get a 'fixed_size' attribute, so when rewriting valueparam to switch, 

-   an uint32_t * pointer could be used instead of void *. 

-

-6. The automatic inclusion of padding requires some complicated coding in the 

-   generator. This is errorprone and could be avoided if all padding is explicitly

-   given in the protocol definition. For variable size fields that require padding, 

-   the pad tag could get a 'fieldref' attribute. That way padding could be handled

+
+There are a number of problematic special cases in XKB. The issues 
+mentioned here are at most partly resolved.
+ 
+1. The are several XxxDoodad structures defined in xkb.xml. They are used
+   in a few lists, but in a rather special way: 
+   The struct "CommonDoodad" is supposed to be a rather generic data type, 
+   combining the most basic Doodad fields that are common in all these structures. 
+   All Doodads are encapsulated in a union type simply called "Doodad". 
+   Now this union is used in subsequent list definitions, aiming at a kind of 
+   'polymorphism': From inspection of the protocol and Xlib, the Doodads are to 
+   be discriminated based on their type field.
+   However the special meaning of the type field is not encoded in the protocol. 
+   Furthermore the TextDoodad and the LogoDoodad are variable size types due to
+   some fields of type CountedString16, thereby turning the union into a 
+   possibly variable size type as well. 
+   However, for lists with variable size elements, special sizeof functions are 
+   required. These cannot be autogenerated as it cannot be referred which 
+   Doodad type to use for the union. 
+   Therefore, the Doodad type structures are unsupported at the moment. 
+
+2. There are still some bugs in xkb.xml: Either certain fields are missing
+   that are required by the protocol, or Xlib simply has another understanding
+   of the protocol. 
+
+3. The interface for accessors should be reviewed. 
+
+4. Currently some bitcases carry 'name' attributes. These could be avoided if 
+   the data within would consist of a singe struct field only. 
+
+5. switch could get a 'fixed_size' attribute, so when rewriting valueparam to switch, 
+   an uint32_t * pointer could be used instead of void *. 
+
+6. The automatic inclusion of padding requires some complicated coding in the 
+   generator. This is errorprone and could be avoided if all padding is explicitly
+   given in the protocol definition. For variable size fields that require padding, 
+   the pad tag could get a 'fieldref' attribute. That way padding could be handled
    a lot easier in the autogenerator. 
\ No newline at end of file