[cairo-commit] cairo-artwork BUGS,1.1,1.2

[Carl Worth]

Committed by: cworth

Update of /cvs/cairo/cairo-artwork
In directory gabe:/tmp/cvs-serv30761

Modified Files:
	BUGS 
Log Message:
Wrap long lines

Index: BUGS
===================================================================
RCS file: /cvs/cairo/cairo-artwork/BUGS,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- BUGS	15 May 2004 12:15:44 -0000	1.1
+++ BUGS	25 Jan 2005 02:05:54 -0000	1.2
@@ -1,14 +1,26 @@
 ---
-cairo-slides.xsl only draws correctly one (or the first) <slide> in <slides>.
+cairo-slides.xsl only draws correctly one (or the first) <slide> in
+<slides>.
 
 PROBLEM
-The problem is with the preceding:: axis in template 'text_y'. On every slide after the first one, the preceding:: axis grabs all previous elements (including from earlier slides) in order to do vertical placement calculation. Slide 2 ends up starting where slide 1 ended off instead of back at the top. This will create a problem even when targeting only one slide as long as there are multiple slides above the targeted slide [see workaround].
+The problem is with the preceding:: axis in template 'text_y'. On
+every slide after the first one, the preceding:: axis grabs all
+previous elements (including from earlier slides) in order to do
+vertical placement calculation. Slide 2 ends up starting where slide 1
+ended off instead of back at the top. This will create a problem even
+when targeting only one slide as long as there are multiple slides
+above the targeted slide [see workaround].
 
 SOLUTION
-Vertical position should only be dependent on elements within the same <slide>. When this is fixed, all slides (if all displayed together) should appear stacked on top of one another instead of top-to-bottom (like a really long page) as they are now.
+Vertical position should only be dependent on elements within the same
+<slide>. When this is fixed, all slides (if all displayed together)
+should appear stacked on top of one another instead of top-to-bottom
+(like a really long page) as they are now.
 
 WORKAROUND
-The workaround right now is to create one file: slides.xml, and then split each slide up into its own file: slide01.xml, slide02.xml, etc. with each file containing its slide in slides, as
+The workaround right now is to create one file: slides.xml, and then
+split each slide up into its own file: slide01.xml, slide02.xml,
+etc. with each file containing its slide in slides, as
 
 <slides title="presentation title">
 	<slide title="slide 2 title">
@@ -16,17 +28,24 @@
 	</slide>
 </slides>
 
-This is kind of a pain, and could be automated, but eventually should be fixed.
-
+This is kind of a pain, and could be automated, but eventually should
+be fixed.
 
 ---
-cairo-slides.xsl is hard-coded (in some places) for dimensions: 1024x768
+cairo-slides.xsl is hard-coded (in some places) for dimensions:
+1024x768
 
 PROBLEM
-Parts of the main slide template (cairo logo, fd.o logo, title) in cairo-slides.xsl are hard-coded for the originally designed dimensions: 1024x768.
+Parts of the main slide template (cairo logo, fd.o logo, title) in
+cairo-slides.xsl are hard-coded for the originally designed
+dimensions: 1024x768.
 
 SOLUTION
-This could be fixed by converting these to calculated values based on one or both of the variables: $slide_width, $slide_height. It's not a huge deal (right now font-size is explicitly specified in slides.xml, so the author is already targeting dimensions), but it does keep one from simply changing the $slide_width and $slide_height variables and having everything just show up nicely
-
+This could be fixed by converting these to calculated values based on
+one or both of the variables: $slide_width, $slide_height. It's not a
+huge deal (right now font-size is explicitly specified in slides.xml,
+so the author is already targeting dimensions), but it does keep one
+from simply changing the $slide_width and $slide_height variables and
+having everything just show up nicely
 
 ---