On Sat, 2005-01-15 at 15:07 +0000, Stuart Ellis wrote: > On Sat, 15 Jan 2005 06:08:08 -0800, "Karsten Wade" <kwade@xxxxxxxxxx> > said: > > On Sat, 2005-01-15 at 13:09 +0000, Stuart Ellis wrote: > > > > > I've done a full batch of screenshots for the Installation Guide, > > > and the masters are here: > > > > > http://www.mythic-beasts.com/~hobb/fedora/screenshots/ > > > > The one I can see looks great. :) The others are 403 forbidden. :( > > D'oh. Now fixed. Yeah, they look good. > I really am totally ignorant about the issues here, especially WRT > generating PDFs... Does this mean that the EPS is simply embedded in > the PDF in the same way that PNGs are embedded into the HTML page, > without twiddling with the dimensions at all ? I live in an A4 country, > but obviously most of the people printing the docs will be using letter > size. There is only one way to find out ... embed the <mediaobject> and see what happens. You can convert the PNG to EPS with the GIMP, then you can manage the sizes, etc. There are utilities to do this, too, making it easy to do batch processing. Same is true with GIMP, I suppose. Best thing is to embed an EPS with a PNG and see what happens when you make pdf: <mediaobject> <imageobject> <imagedata fileref="./figs/1-boot.eps" format="eps"> </imageobject> <imageobject> <imagedata fileref="./figs/1-boot.png" format="png"> </imageobject> <textobject> <para> Fedora boot screen. </para> </textobject> </mediaobject> I put the EPS first out of habit from a SGML DocBook workaround, it's kind of a magic formula. So, use it with a grain of salt. > Official PPC support is on the FC4 features post that Bill Nottingham > sent to the devel list, so we probably have to assume that this document > will have to support additional architectures... I think that the only > parts of the document that would vary by architecture would be the boot > loader section and maybe the partitioning, but don't actually own any > 64-bit or PPC systems. Good point, I just saw that. I think the reason for different directories was to make <chapter>s more modular, so multiple guides could be built from the same pool. I don't think this applies much to our situation. I would say your convention is reasonable, and you can add a field on the end for arch where appropriate. If you haven't seen the conditionals in practice in XML, they let you mark an area of the markup as being specific to a certain condition. For example, you have a place in the install where PPC is different form x86, with different screenshots. You write up the two pieces and put them together in the XML, each marked with a conditional. Then you have build targets for the different archs, which pick up their own conditionals and ignore the others. - Karsten -- Karsten Wade, RHCE, Sr. Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
