SVG support in CEGUI - Revision history

Ident: Ident moved page The Lederhosen project to SVG support in CEGUI

2014-03-19T23:43:31Z

Ident moved page The Lederhosen project to SVG support in CEGUI

Ident: /* Decisions that have to be made */

2013-10-05T23:24:00Z

‎Decisions that have to be made

Ident: /* Decisions that have to be made */

2013-10-05T23:23:40Z

‎Decisions that have to be made

Ident: /* Decisions that have to be made */

2013-10-05T23:21:25Z

‎Decisions that have to be made

Ident: /* Decisions that have to be made */

2013-10-05T21:35:09Z

‎Decisions that have to be made

Ident: /* Decisions that have to be made */

2013-10-02T02:49:24Z

‎Decisions that have to be made

Ident: /* Decisions that have to be made */

2013-10-02T02:48:34Z

‎Decisions that have to be made

Ident: /* Decisions that have to be made */

2013-10-02T02:17:37Z

‎Decisions that have to be made

Ident: /* Decisions that have to be made */

2013-10-02T02:17:22Z

‎Decisions that have to be made

Ident at 01:20, 2 October 2013

2013-10-02T01:20:54Z

@@ Line 20: / Line 20: @@
 Notes:
-The new classes will be, as much as possible based, on the SVG standard and carry SVG as prefix.
+The new classes will be, as much as possible based, on the SVG standard and their names will carry SVG as prefix.
 '''Parsing'''

@@ Line 20: / Line 20: @@
 Notes:
-<strike>Probably SVGImage should rather be called VGImage or VectorImage or VectorGraphicsImage. This is because it should be easily possible to make that the class would not require actual SVG data but instead only require shape information for drawing. The SVG data can be converted into such abstract shape information. That way users can create their own shape information and which can be used in a VGImage. None of the names should refer to "SVG" as a name in my opinion, except for the SVG parser itself. Everything after the parser should be "general" although the whole data structures and drawing process will be designed in the first line to go well along with the SVG file standard and its definition of vector graphics.
+The new classes will be, as much as possible based, on the SVG standard and carry SVG as prefix.
-−
-We should probably think of a general naming concept, maybe using a common prefix for all files such as "VG-", and also maybe seperate all Vector Graphics related files into its own src/includes folder such as done with "widgets", unless this is not desired.</strike>
-Everything will be as much as possible based on SVG and carries SVG as prefix if it is a vector graphics related class.
 '''Parsing'''

@@ Line 16: / Line 16: @@
 '''SVG loading and parsing:'''
 * An SVG file can be referenced from within an Imageset file and used just in the same way as texture atlases are used (Pos+Size define an Image in it) (<span style="color:#27a41a">'''yes, already implemented that way'''</span>)
-* An Image defined in an SVG-Imageset can also address a group/layer using an optional "Group" or "Layer" attribute. This means that only data from the specified group will be used for the Image.
+* An Image defined in an SVG-Imageset can also address a group/layer using an optional "Group" or "Layer" attribute. This means that only data from the specified group will be used for the Image. (<span style="color:#aeb000">'''not yet implemented'''</span>)
-* When defining an Image in the Imageset an alternative to defining an area inside the Imageset's SVG file an Image should also be able to be referenced directly as a seperate SVG file directly. In that case the Image's area will span over the whole SVG image. A pos/size definition should in that case not be valid in XML because for that a seperate imageset should be created instead.  (<span style="color:#ced000">'''not yet implemented'''</span>)
+* When defining an Image in the Imageset an alternative to defining an area inside the Imageset's SVG file an Image should also be able to be referenced directly as a seperate SVG file directly. In that case the Image's area will span over the whole SVG image. A pos/size definition should in that case not be valid in XML because for that a seperate imageset should be created instead.  (<span style="color:#aeb000">'''not yet implemented'''</span>)
 Notes:
-Probably SVGImage should rather be called VGImage or VectorImage or VectorGraphicsImage. This is because it should be easily possible to make that the class would not require actual SVG data but instead only require shape information for drawing. The SVG data can be converted into such abstract shape information. That way users can create their own shape information and which can be used in a VGImage. None of the names should refer to "SVG" as a name in my opinion, except for the SVG parser itself. Everything after the parser should be "general" although the whole data structures and drawing process will be designed in the first line to go well along with the SVG file standard and its definition of vector graphics.
+<strike>Probably SVGImage should rather be called VGImage or VectorImage or VectorGraphicsImage. This is because it should be easily possible to make that the class would not require actual SVG data but instead only require shape information for drawing. The SVG data can be converted into such abstract shape information. That way users can create their own shape information and which can be used in a VGImage. None of the names should refer to "SVG" as a name in my opinion, except for the SVG parser itself. Everything after the parser should be "general" although the whole data structures and drawing process will be designed in the first line to go well along with the SVG file standard and its definition of vector graphics.
-We should probably think of a general naming concept, maybe using a common prefix for all files such as "VG-", and also maybe seperate all Vector Graphics related files into its own src/includes folder such as done with "widgets", unless this is not desired.
+We should probably think of a general naming concept, maybe using a common prefix for all files such as "VG-", and also maybe seperate all Vector Graphics related files into its own src/includes folder such as done with "widgets", unless this is not desired.</strike>
 '''Parsing'''
-* Should a warning be thrown if the svg file's version does not match SVG Tiny 1.2 (or lower) version? As we won't fully support all features of any profile either way, this might be redundant and it should just be documented in the CEGUI docs and SVG class docs what is supported and what isn't. (<span style="color:#ced000">'''undecided'''</span>)
+* Should a warning be thrown if the svg file's version does not match SVG Tiny 1.2 (or lower) version? As we won't fully support all features of any profile either way, this might be redundant and it should just be documented in the CEGUI docs and SVG class docs what is supported and what isn't. (<span style="color:#aeb000">'''undecided'''</span>)
 == Possible use-cases for SVG Images ==

@@ Line 13: / Line 13: @@
 * A class called VGShapeData, VectorShapeData, VectorData or similar, will contain the abstract information on the shapes which is used in SVGImage to be cached and drawn (<span style="color:#27a41a">'''yes, implemented as SVGData with similar behaviour'''</span>)
 * SVGImage will contain a reference to a shape-data class. This means that multiple SVGImages can share the same shape data. The question is if this is necessary (use-case?). If this data was shared and the user modified this data, all VGImages would have to be updated. An alternative would be that the shape-data class can only be referenced once, but can be copied and then altered if required. (<span style="color:#27a41a">'''yes, SVGImage contains a reference to a possibly SVGData object that can be used by multiple (or none) SVGImages'''</span>)
-* CEGUI::VectorShape (or similar) will be a superclass for all draw shapes. These can be constructed manually but will also be used directly by the SVG parser. The mentioned ShapeData class will store the various shapes which can then be used for creating actual geometry in SVGImage. (<span style="color:#27a41a">'''SVGData contains the different shapes. SVGBasicShape is the superclass for all SVG shapes'''</span>)
+* CEGUI::VectorShape (or similar) will be a superclass for all draw shapes. These can be constructed manually but will also be used directly by the SVG parser. The mentioned ShapeData class will store the various shapes which can then be used for creating actual geometry in SVGImage. (<span style="color:#27a41a">'''SVGData contains the different shapes. SVGBasicShape is the superclass for all Basic Shapes defined by SVG'''</span>)
 '''SVG loading and parsing:'''
-* An SVG file can be referenced from within an Imageset file and used just in the same way as texture atlases are used (Pos+Size define an Image in it) (<span style="color:#ced000">'''undecided'''</span>)
+* An SVG file can be referenced from within an Imageset file and used just in the same way as texture atlases are used (Pos+Size define an Image in it) (<span style="color:#27a41a">'''yes, already implemented that way'''</span>)
 * An Image defined in an SVG-Imageset can also address a group/layer using an optional "Group" or "Layer" attribute. This means that only data from the specified group will be used for the Image.
-* When defining an Image in the imageset, as an alternative to a relative definition in respect to the Imageset's SVG file, each Image should also be able to reference a specific SVG file directly which would be then used for this image as a whole in the process of parsing the Imageset. A pos/size definition should in that case not be possible because that a seperate imageset should be created for.  (<span style="color:#ced000">'''undecided'''</span>)
+* When defining an Image in the Imageset an alternative to defining an area inside the Imageset's SVG file an Image should also be able to be referenced directly as a seperate SVG file directly. In that case the Image's area will span over the whole SVG image. A pos/size definition should in that case not be valid in XML because for that a seperate imageset should be created instead.  (<span style="color:#ced000">'''not yet implemented'''</span>)
 Notes:

@@ Line 13: / Line 13: @@
 * A class called VGShapeData, VectorShapeData, VectorData or similar, will contain the abstract information on the shapes which is used in SVGImage to be cached and drawn (<span style="color:#27a41a">'''yes, implemented as SVGData with similar behaviour'''</span>)
 * SVGImage will contain a reference to a shape-data class. This means that multiple SVGImages can share the same shape data. The question is if this is necessary (use-case?). If this data was shared and the user modified this data, all VGImages would have to be updated. An alternative would be that the shape-data class can only be referenced once, but can be copied and then altered if required. (<span style="color:#27a41a">'''yes, SVGImage contains a reference to a possibly SVGData object that can be used by multiple (or none) SVGImages'''</span>)
-* CEGUI::VectorShape (or similar) will be a superclass for all draw shapes. These can be constructed manually but will also be used directly by the SVG parser. The mentioned ShapeData class will store the various shapes which can then be used for creating actual geometry in SVGImage. (<span style="color:#ced000">'''undecided'''</span>)
+* CEGUI::VectorShape (or similar) will be a superclass for all draw shapes. These can be constructed manually but will also be used directly by the SVG parser. The mentioned ShapeData class will store the various shapes which can then be used for creating actual geometry in SVGImage. (<span style="color:#27a41a">'''SVGData contains the different shapes. SVGBasicShape is the superclass for all SVG shapes'''</span>)
 '''SVG loading and parsing:'''
 * An SVG file can be referenced from within an Imageset file and used just in the same way as texture atlases are used (Pos+Size define an Image in it) (<span style="color:#ced000">'''undecided'''</span>)

← Older revision	Revision as of 23:43, 19 March 2014
(No difference)

@@ Line 11: / Line 11: @@
 * SVGImage will be a subclass of CEGUI::Image (<span style="color:#27a41a">'''yes'''</span>)
 * SVGImage contains the cached information required for rendering (<span style="color:#27a41a">'''yes, it is cached inside GeometryBuffers'''</span>)
-* A class called VGShapeData, VectorShapeData, VectorData or similar, will contain the abstract information on the shapes which is used in SVGImage to be cached and drawn (<span style="color:#27a41a">'''Implemented as SVGData with similar behaviour'''</span>)
+* A class called VGShapeData, VectorShapeData, VectorData or similar, will contain the abstract information on the shapes which is used in SVGImage to be cached and drawn (<span style="color:#27a41a">'''yes, implemented as SVGData with similar behaviour'''</span>)
 * SVGImage will contain a reference to a shape-data class. This means that multiple SVGImages can share the same shape data. The question is if this is necessary (use-case?). If this data was shared and the user modified this data, all VGImages would have to be updated. An alternative would be that the shape-data class can only be referenced once, but can be copied and then altered if required. (<span style="color:#ced000">'''undecided'''</span>)
 * CEGUI::VectorShape (or similar) will be a superclass for all draw shapes. These can be constructed manually but will also be used directly by the SVG parser. The mentioned ShapeData class will store the various shapes which can then be used for creating actual geometry in SVGImage. (<span style="color:#ced000">'''undecided'''</span>)

@@ Line 6: / Line 6: @@
 '''Module-integration:'''
 * SVGImage and related files will be a part of CEGUI Core-library (<span style="color:#27a41a">'''yes'''</span>)
-* Vector graphics rendering related files will be part of CEGUI Core-library (<span style="color:#27a41a">'''yes'''</span>)
+* Vector graphics rendering related files will be part of CEGUI Core-library (<span style="color:#27a41a">'''yes, they are in the subfolder "svg"'''</span>)
-* The SVG File loading and parsing will  be part of CEGUI Core-library (<span style="color:#27a41a">'''yes'''</span>)
+* The SVG File loading and parsing will  be part of CEGUI Core-library (<span style="color:#27a41a">'''yes, it is implemented in SVGData'''</span>)
 '''Classes and structures:'''
 * SVGImage will be a subclass of CEGUI::Image (<span style="color:#27a41a">'''yes'''</span>)