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/
Two rather silly queries regarding these:
1) The Documentation Guide specifies a width but not a height. What would be the best height to use ?
2) There are a lot of images, which means that organising them is a problem in itself. Is there a naming convention that I should use for the files ?
FWIW, these were captured using VMWare. I found that many of the required images couldn't be captured with anaconda's --auto-screenshot because they were either text mode, or were dialog boxes. --
Stuart Ellis s.ellis@fastmail.co.uk
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:
The one I can see looks great. :) The others are 403 forbidden. :(
Two rather silly queries regarding these:
- The Documentation Guide specifies a width but not a height.
What would be the best height to use ?
Generally, I'd say that if they are the correct width, the correct height is already there. Don't worry about it unless you have one that is particularly tall. In that case, consider reconfiguring the screenshot. None of that applies to Anaconda, since everything has the right aspect ratio.
Might be different rule of thumb for PS/PDF, maybe four inches for letter size, you can calc the cm for A4 yourself :).
- There are a lot of images, which means that organising them is a
problem in itself. Is there a naming convention that I should use >
for the files ?
It appears you have them named in terms of the order they appear, with some nesting, and the name/nature of the screen. That seems about as sane a method as I can think of.
I've seen them dropped into unique folders, one folder for every section of the install. This helps if you have a guide that covers multiple architectures and might have different screenshots for the same part of Anaconda. I don't think this applies for FC.
FWIW, these were captured using VMWare. I found that many of the required images couldn't be captured with anaconda's --auto-screenshot because they were either text mode, or were dialog boxes.
Cool, I'm glad you have VMWare available. For FC4, I'll help you look into Anaconda's screenshooter. If it is inadequate for the task, we'll file some feature requests. :)
cheers - Karsten
On Sat, 15 Jan 2005 06:08:08 -0800, "Karsten Wade" kwade@redhat.com 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:
The one I can see looks great. :) The others are 403 forbidden. :(
D'oh. Now fixed.
Two rather silly queries regarding these:
- The Documentation Guide specifies a width but not a height.
What would be the best height to use ?
Generally, I'd say that if they are the correct width, the correct height is already there. Don't worry about it unless you have one that is particularly tall. In that case, consider reconfiguring the screenshot. None of that applies to Anaconda, since everything has the right aspect ratio.
Might be different rule of thumb for PS/PDF, maybe four inches for letter size, you can calc the cm for A4 yourself :).
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 are a lot of images, which means that organising them is a
problem in itself. Is there a naming convention that I should use >
for the files ?
I've seen them dropped into unique folders, one folder for every section of the install. This helps if you have a guide that covers multiple architectures and might have different screenshots for the same part of Anaconda. I don't think this applies for FC.
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.
FWIW, these were captured using VMWare. I found that many of the required images couldn't be captured with anaconda's --auto-screenshot because they were either text mode, or were dialog boxes.
Cool, I'm glad you have VMWare available. For FC4, I'll help you look into Anaconda's screenshooter. If it is inadequate for the task, we'll file some feature requests. :)
That would be great. Even with the semi-official patch VMWare is very cranky on a FC3 host, and I don't expect that VMWare will track Fedora development on an ongoing basis. So I've started looking at alternate solutions. --
Stuart Ellis s.ellis@fastmail.co.uk
On Sat, 2005-01-15 at 15:07 +0000, Stuart Ellis wrote:
On Sat, 15 Jan 2005 06:08:08 -0800, "Karsten Wade" kwade@redhat.com 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:
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
On Sat, Jan 15, 2005 at 01:09:52PM +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/
Two rather silly queries regarding these:
- The Documentation Guide specifies a width but not a height. What
would be the best height to use ?
When you resize it, contrain proportions. The width maximum is for online viewing. Height doesn't matter as much. When we generate PDFs, the height will matter more because of page breaks, but the anaconda screenshots should be fine.
- There are a lot of images, which means that organising them is a
problem in itself. Is there a naming convention that I should use for the files ?
The filenames you've used look fine -- descriptive of the screen itself. One suggestion I would make is to remove the numbers. Screens tend to be moved around in anaconda, and it could be confusing down the line as we start working on revisions of the Installation Guide.
FWIW, these were captured using VMWare. I found that many of the required images couldn't be captured with anaconda's --auto-screenshot because they were either text mode, or were dialog boxes.
There is a way to capture screenshots for the "text" screens, although I've never quite figured it out. Someone on the anaconda team might be able to enlighten us if they are watching this list.
For the dialogs, I've found success in using the manual screenshot feature of anaconda: Shift-PrtScreen. I can't remember, but you might have to use The GIMP to crop the dialog out after that.
Tammy
On Sun, 23 Jan 2005 19:37:36 -0500, "Tammy Fox" tfox@redhat.com said:
On Sat, Jan 15, 2005 at 01:09:52PM +0000, Stuart Ellis wrote:
- The Documentation Guide specifies a width but not a height. What
would be the best height to use ?
When you resize it, contrain proportions. The width maximum is for online viewing. Height doesn't matter as much. When we generate PDFs, the height will matter more because of page breaks, but the anaconda screenshots should be fine.
The dimensions for the EPS images is the bit I don't understand very clearly. When I run 'make pdf' I get an A4 layout, but presumably the EPS has to be sized so that it looks OK on US Letter as well.
- There are a lot of images, which means that organising them is a
problem in itself. Is there a naming convention that I should use for the files ?
The filenames you've used look fine -- descriptive of the screen itself. One suggestion I would make is to remove the numbers.
OK, I'll amend these.
FWIW, these were captured using VMWare. I found that many of the required images couldn't be captured with anaconda's --auto-screenshot because they were either text mode, or were dialog boxes.
There is a way to capture screenshots for the "text" screens, although I've never quite figured it out. Someone on the anaconda team might be able to enlighten us if they are watching this list.
Looking back through the discussions on screenshots, I found this message from Karsten advising that the functionality was broken:
https://www.redhat.com/archives/fedora-docs-list/2004-August/msg00347.html
I admit that I didn't experiment much, as I knew that I could get VMWare to produce something workable. Hopefully we can hash out a process for FC4. On my to-do list is trialing QEmu as a VMWare replacement, and that would get around the dependency on non-Free software, even though it's not very a elegant solution. --
Stuart Ellis s.ellis@fastmail.co.uk
On Tue, 2005-01-25 at 01:56 +0000, Stuart Ellis wrote:
https://www.redhat.com/archives/fedora-docs-list/2004- August/msg00347.html
On my to-do list is trialing QEmu as a VMWare replacement, and that would get around the dependency on non-Free software, even though it's not very a elegant solution.
You might also want to try Xen. Lots of activity happening in development.
- Karsten
On Tue, 25 Jan 2005 06:02:50 -0800, "Karsten Wade" kwade@redhat.com said:
On Tue, 2005-01-25 at 01:56 +0000, Stuart Ellis wrote:
https://www.redhat.com/archives/fedora-docs-list/2004- August/msg00347.html
On my to-do list is trialing QEmu as a VMWare replacement, and that would get around the dependency on non-Free software, even though it's not very a elegant solution.
You might also want to try Xen. Lots of activity happening in development.
It sounds stunning, and I'll definitely be giving it a go when test 1 comes out. I'm interested in QEmu because it looks like an almost drop-in replacement for VMWare - about the same level of invasiveness (or less) and it even claims to take VMWare disk images. I need to keep Windows images around... --
Stuart Ellis s.ellis@fastmail.co.uk
Hi
I'm interested in QEmu because it looks
like an almost drop-in replacement for VMWare - about the same level of invasiveness (or less) and it even claims to take VMWare disk images. I need to keep Windows images around...
yes qemu is more close to what vmware does but the amount of work being done to integrate xen would mean that you can potentially do the same thing with xen itself. just something to keep in mind
===== Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
Karsten,
Have you considered Wine, at:
It's an open source software implementation of the Windows API in Wine. You don't need a Windows license You can install your Windows programs from the CD into a "fake" C drive (symlinked to a Linux directory) and run it with:
$ wine windows-program.exe
Tools such as regedit are available as well, for tweaking the installation.
Ira
docs@lists.stg.fedoraproject.org
-
Ira Krakow -
Karsten Wade -
Rahul Sundaram -
Stuart Ellis -
Tammy Fox