Date: Wed, 5 Jul 2000 16:03:31 -0700 (PDT) From: papowell@astart.com To: doc@freebsd.org, nik@freebsd.org, papowell@astart.com Subject: Re: Images in the documentation Message-ID: <200007052303.QAA23121@h4.private>
next in thread | raw e-mail | index | archive | help
> > and figuring out ways to update illustrations > > which used screen dumps. > > How do you mean? > > > Discovered that there were no way to automate the screen dumps > > easily, hired a trained monkey to document how to update the > > illustrations and then had them do the illustrations (remember to > > put Prozac in trained monkey's Orange Juice BEFORE you tell him that you > > changed the title on the screen for all 30 of the screen dumps you > > use). > > Screen dumps aren't going to be that much hassle for us, I suspect. Partly > because we're not going to use a great deal of them (certainly not in the > early days anyway), and partly because they're so easy to generate on > FreeBSD. As for standards, that just requires a chapter in the Primer, > which I, or someone else, will have to write. We'll need a common look > for X screenshots (same window manager, colour scheme, that sort of thing) > and maximum image widths that we want, but that's about it. Certainly for > a volunteer project anyway. > > > I hate the idea of Yet Another Graphics Descrition Language and Tool. > > New output format does not imply new tools. As I say, the commercial > packages are gaining support for it, and Sketch can import EPS and write > SVG, so people can go on using the same EPS generating tools they always > have been. The eps-converted-to-svg probably won't be as easy to > manipulate programmatically as something that was generated in an SVG > aware tool, which is unfortunate, but there's no much we can do about > that. Yes, I am aware of this. But it is Yet Another PITA. > > > The only way that I see that this would be better is if there was a way to > > leverage this: > > > > a) Make it easier to automate the process of getting illustrations. > > (Screen Dumps! Hatums Screen Dumps! Bad! Evil! Cause you cannot > > modify text easily. > > For text mode screen dumps you can -- they'll be a 4000 byte dump of the > screen memory, where each pair of a bytes is the ASCII code and the colour > code respectively. Editing these after they've been produced is relatively > simple. Yes, I agree on this, I forgot that most of the setup stuff is 'text screendumps'. The ones we were using were Xterm screendumps, actually 'Xterm window' dumps. > > For those wondering why we'd do screendumps in text mode -- I want to > preseve the colours and general look and feel. A non-graphic version of > the text can still be included (and will be, and probably be automatically > generated), but the colour version gives a bit more impact, looks more > professional, and probably communicates more to the reader as well. > > For graphics dumps (shots of X windows, that sort of thing) this will be > a problem. Fortunately, we won't have many of these to contend with, I > think. > I just had a sudden thought: What happened to the project/tool that allow you to do playback of X sessions? I remember reading about (Freshmeat?) but I can't find it in my archives and a simple minded search of Freshmeat did not turn it up. This might be the solution to the problem of screendumps. Patrick Powell Astart Technologies, papowell@astart.com 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 858-874-6543 FAX 858-279-8424 LPRng - Print Spooler (http://www.astart.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007052303.QAA23121>