RE: [Groff] DESC question
On 21-Feb-05 Ersin Akinci wrote: > Hi everyone, > > I get the feeling this is going to be a RTFM question, but I haven't > been able to find a straight answer anywhere...What exactly is the > DESC file? When I type in "groff" on my Debian testing box all it > does is wait for input (it doesn't return any output). That, of course, is normal behaviour (as I dare say you know). > But I recently > compiled groff from scratch in another directory with a seperate > native toolchain I've been building, and when I run groff with no > options, this is the result: > > thebeast:/usr/src/groff-1.19.1# groff > groff: can't find `DESC' file > groff:fatal error: invalid device `ps' > > The groff on my Debian system is 1.18.1 and the groff I compiled is > 1.19.1. I compiled the new groff statically, could that be a problem? > Is this a bug, or do I need to set up a DESC file? When you run groff, it needs to be able to *find* a DESC file. Normally, the path to this file should be compiled-in when groff is compiled. This may be a matter of running 'config' with correct options as the first stage of the compilation. The DESC file is in the subdirectory [...]/groff/[xxx]/font/[device] where [...] is the path from / to the groff tree -- often /usr/share and [xxx] (which may be absent) is perhaps a version-specific subdirectory of [...]/groff. [device] is the subdirectory of groff corresponding to the specific device for which output is formatted (by default "devps", the PostScript device). In a standard Red Hat 9 distribution of groff, for instance, I have /usr/share/groff/1.18.1/font/devps which contains ABBMI DESC HIMPBI symbolsl.pfa zapfdr.pfa ABI BMR download HNB NB PITBZCMI AICB G HNBI NBI PRTBI ZD ARCBI generate HNI NI prologue text.enc ZDR BMB CI HBHNR NR S TI BMBI CR HBI HRPB SSTR and as you can see there is a "DESC" in there. There is also (or should be) a "DESC" for each other device under .../font. The DESC file is a "device description file" which provides groff with many kinds of information about the font characteristics available for the device in whose subdirectory it occurs. Details can be studied in the man page man groff_font Hoping this helps! Basically, the problem you need to sort out is how to make the path to .../font known to groff when you compile. If that wasn't done, you should still be able to set this information in the environment variable GROFF_FONT_PATH: for an explanation of this and similar things see "man groff". Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 21-Feb-05 Time: 09:02:26 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] The quest for a high-end typesetting system: A few q
On 10-Mar-05 Mats Broberg wrote: > [...] > Another general groff question: > > Does groff handle floats, i.e. graphics that does not necessarily need > to be inserted at a specific point on the page but are allowed to queue > until there is enough space to put them without getting alot of white > space? I found a a few references to floats in the UTP book, but only > in > relation to something called "displays". > > Best regards, > Mats Broberg This depends on the macro package. In the 'ms' macros, for instance, there is a concept of a "keep" -- a block of material which must stay together on one page. Thus the "immediate keep" .KS [] .KE will encapsulate the formatted [] and, if there is room for it on the current page, will output it there and then; but, if not, then there will be an immediate break to a new page and [] will be placed at the top of this. There is also the "floating keep" which works like what you are asking about: .KF [] .KE If there is room for the formatted [] on the current page, then it goes there immediately. Otherwise, it is kept in reserve, and subsequent material is output on the current page until the page is full, whereupon there will be a page break. The formatted [] is then output at the top of the new page, after which the material from the bottom of the previous page continues below the []. This generally works well, to the point where you can write .KF [...1] .KE .KF [...2] .KE .KF [...3] .KE etc., and (supposing for example that each of these is too big for more than one of them on a page) you will get [...1] at the top of the next page as described above, then [...2] on the following page, then [...3] on the page after that, in all cases with the surrounding text continuiung smoothly past the []s at the tops of the pages. However, there can be some conflicts or inconsistencies with this mechanism. For instance, if [] is a figure with a caption and you make an Table-of-Contents entry of the caption text inside the ".KF ... .KE", then the page number attached to the index entry will be the page number on which the "keep" was first encountered, and not the page number on which it is printed. It is possible to work round things like this, but it can be subtle! Hoping this helps, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 10-Mar-05 Time: 17:40:39 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] questions about postscript and tex/latex output
Hi Robert, On 12-Mar-05 Robert Dodier wrote: > Hi everyone, > > I have a couple of simple questions which I hope you > can help me with. The files I am working with (composed > in 1985) are composed with MS macros. > > (1) The postscript output option (-T ps) puts the stuff > between .DS/.DE in variable-width font, although I would > have expected fixed width font. Is there a way to cajole > groff into considering .DS/.DE stuff to be fixed width font? > It's OK with me if the answer is "yes, throw in this > macro .FOOBAR before every .DS" or something like that. There's no reason to expect fixed-width font for what is between .DE and .DE -- what you get is, without additional measures, in the ambient font (i.e. what is in use when ".DE" is invoked). You can, however, easily arrange for a special font for such displays. For instance .DS .ft CR ...text of display... .ft .DE and then it will be in Courier Roman (a fixed-width font) for the duration of the display, reverting afterwards to what it was before. > (2) Is there a way to generate tex or latex output from groff? The default output device with groff is the PostScript device (as if you had invoked it with "groff -Tps ... "). You can produce TeX-compatible "device-independent" output with groff -Tdvi ... -o TeX_file.dvi troff_file which will generate a ".dvi" file to which you can apply the TeX commands for generating device-specific output (e.g. dvips to convert the .dvi file to PostScript). Beware, however, that a lot of the characters in the devdvi fonts have different groff names from the corresponding characters in (say) the devps fonts. What you *cannot* do (at any rate not using groff) is convert a groff "source" file into a TeX/LaTeX "source" file on which you can then run TeX (or edit as a TeX file). Even if there was some program which claimed to do such a conversion, you should not expect good results. The two programs, groff and TeX, are conceived along different lines, and neither would map onto the other. The fact that each offers users a rich palette of possibilities to define their own macros, etc., means that a conversion program would have to cope with anything of this kind that the user might think of. > I've RTFM and searched the mailing list archives but I wasn't > able to find answers to these questions. If anyone can shed > light on these questions I will be very much obliged. > > All the best, > Robert Dodier It would be worth studying the overall structure of a groff run. Apart from the use of pre-processors (whose function is merely to convert passage of "special description" -- e.g. the equation description language "eqn", or the graph description language "pic" or the table description language "tbl" -- into groff language, prior to submitting everything to groff for processing), groff takes an input stream, processes it according to its contents and the device specified with "-T", and outputs a stream in "intermediate language" (described in "man groff_out"). This intermediate-language stream is then submitted to a device-specific post-processor -- grops for PostScript, grodvi for ".dvi", grohtml for HTML, grotty for fixed-width terminal output, etc. Already encapsulated in the intermediate stream are many fine details of the formatting, in particular precise positions and motions for the placement of characters, and detailed specifications of font changes, etc. This is all at a much lower level than what TeX source code corresponds to, and a postprocessor to generate TeX source would have to undo a lot of this. (In passing, I wonder what one might call such a post-processor; "grotex"? Maybe "grotesk"?) Hoping this helps, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 12-Mar-05 Time: 01:34:48 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] developers only?
On 29-Mar-05 Otavio Exel wrote: > Groff'ers, > > I see this list is mainly for groff developers; > could you please recommend a list for > groff users (actually groff newbies)? > > []s, The list is for everybody! True, recent postings have mainly been on "development" types of topics, but that's just how it happened. If you're a beginner, just ask your questions. We will all do our best to help. Best wishes, Ted. -------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 29-Mar-05 Time: 20:54:39 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] developers only?
On 29-Mar-05 Otavio Exel wrote: > [...] > I'm printing the lyrics of a CD; I want it in 2-col; so I did > > .2c > .nf > > I wanted groff to *not* join short lines but break long lines; > Short lines were not joined, ok! > But groff did not break the long lines :-)) > - Long lines in the first column invaded the second column > - Long lines in the second column were truncated > > How do I get groff to split but don't join? > > I'm using -me and groff 1.17.2 (debian stable); I'll make a suggestion. This uses the 'ms' macros (which I'm more familiar with than 'me' so I know what I'm doing!). The following is the 'input file' for groff: .nr PD 0 .de newXP .XP .nh .ad l .. .blm newXP .2C This is a mixture Of some short lines and some long lines Including some lines which are very long indeed and can be typed on several consecutive lines with no blank line between them. The blank lines Will trigger the blank line macro Which is defined by the macro definition .blm above, which starts an exdented paragraph (the first line left-justified, all subsequent lines indented, until the next one). The .nr PD 0 definition sets the paragraph drop (the spacing between paragraphs) to 0 So that the new lines of the lyric will be recognised by starting on the left. .sp When you do want a space For instance between verses of a lyric You can use the .sp command. If you put the above (between ...//...//...) into say temp.tr and then run groff -Tascii -ms temp.tr > temp.out you should find that temp.out contains == This is a mixture Of some short lines and some long lines Including some lines which are very long indeed and can be typed on several consecutive lines with no blank line between them. The blank lines Will trigger the blank line macro Which is defined by the macro definition .blm above, which starts an exdented paragraph (the first line left- justified, all subsequent lines indented, until the next one). The .nr PD 0 definition sets the paragraph drop (the spacing between paragraphs) to 0 So that the new lines of the lyric will be recognised by starting on the left. When you do want a space For instance between verses of a lyric You can use the .sp command. Because of ".2C" this is the first column of a two-column layout, hence the short lines as printed. Other things you need to know, not explained in the "lyrics", are: ".nh" supresses hyphenation ".ad l" does "left adjustment" but not "right adjustment" as well, so that the automatic expansion of inter-word spaces which normally cause the line to be filled out to its full length does not take place. The other things are explained in the lyrics. Note in particular the blank line following ".sp" in the input file. Hoping this helps! Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 30-Mar-05 Time: 00:04:49 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] developers only?
On 29-Mar-05 Ted Harding wrote: > On 29-Mar-05 Otavio Exel wrote: >> [...] >> I'm using -me and groff 1.17.2 (debian stable); > > I'll make a suggestion. This uses the 'ms' macros (which > I'm more familiar with than 'me' so I know what I'm doing!). > [...] Now that I've had a detailed look at the 'me' macros, I see that there is nothing in 'me' corresponding to the ".XP" macro in 'ms', so to use the mechanism I proposed in my previous post you'd need to switch to the 'ms' macros. However, looking at Tadziu Hoffman's neat use of ".ti" with 'me' macros gives the idea that you can, again, exploit the blank-line-macro idea so that you don't have to bother with ".xx" at the start of each line of the lyrics, i.e. each new line of the lyric is preceded by a blank line in the input file, which is much less fussy to type than the ".xx" at the start. So I've modified Tadziu's example as follows: cut 8< here- .2c .fi This is just some comaprison text to demonstrate the width of the column. .de xx .br .ti 0 .. .blm xx .in +2m A normal-length line of my favorite song A very very very very very very very very long line of my favorite song A short line A normal-length line of my favorite song .in -2m cut >8 here- With the above in "temp2.tr", when I run groff -Tascii -me temp2.tr > temp2.txt I get: This is just some comaprison text to demonstrate the width of the column. A normal-length line of my favorite song A very very very very very very very very long line of my favorite song A short line A normal-length line of my favorite song Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 30-Mar-05 Time: 10:30:03 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Spam from list member addresses
On 31-Mar-05 Peter Schaffter wrote: > Hi. > > I got two pornographic-sounding spams today, one apparently from > Werner, the other apparently from Ted Harding. Rather than wait to > see if these are isolated incidents, I'm cut 'n' pasting both > emails with full headers into this post. > > I'm not an expert in mail header forensics, but someone else may > spot something useful. I'm operating on the "an ounce of > prevention is worth a pound of cure" theory here. I can deal with > spams like these easily myself, provided they remain sporadic. But > in the event they become systematic and affect other list members, > these two messages may prove useful in isolating the source of the > problem. Thanks, Peter, for putting up this info. We've been here before, from time to time, over recent years. There's been a new cluster of these since a couple of months ago, and I started collecting them to see if there was a pattern. There's not a lot any of us can do to stop these being sent, since just about eveything in them is spoofed. The only solution (and that's only got a thin chance, seing how they operate) would be to install filters on the servers which receive them in the first place. Out of the 25 messages I've collected since 14 Feb 2005, 13 were sent to the groff list of which 11 were sent in my name and 2 in Werner's (the "senders" in the "From:" headers are of course spoofed). The remaining 12 were sent directly to me (not via the list): 10 in my name and 1 in Werner's. All the ones sent to the groff list faked their "helo" identity to be the IP address 199.232.76.166 of rev-c76-166.gnu.org, which is presumably the server at gnu.org which is the front door of the gnu.org mail system, though the headers say that they were received by monty-python.gnu.org (IP address 199.232.76.173). The ones sent directly to me helo'd themselves variously to SMTP servers at mcc.ac.uk/man.ac.uk: -- 130.88.200.94 probity.mcc.ac.uk -- 130.88.200.93 serenity.mcc.ac.uk -- 130.88.13.7 curlew.cs.man.ac.uk -- 130.88.94.110 gannet.scg.man.ac.uk in each case idenitifying itself in "helo" with the same IP address as it was talking to. The "Received: from ..." headers give either of -- 194.2.232.250 nat.isep.fr -- 218.254.223.228 cm218-254-223-228.hkcable.com.hk as the source servers. "Werner"'s two are from nat.isep.fr and "mine" are a mixture of both. In previous clusters of these, it hasn't been just Werner and me who have been spoofed as senders -- one or two other people on the list have also come up. What seems to be a bit special about this is that the groff list is the only one, of the many I'm on, where this sort of pattern as described above occurs. I don't know what to suggest about it. It's extremely irritating, and could be misinterpreted by people who don't understand how it works, leaving a few of us with bad reputations! What's intriguing is that only 3-4 groff subscribers have ever appeared as "senders", most often myself. If this were one of the standard spoofers, then "senders" would be randomly chosen from someone's address book or whatever, and by now many of us should have appeared. Nor am I aware of this particular genre appearing on other lists to which I belong (nor sent to other lists which I manage, where I would see them in any case whether they made it through or not). This tends to suggest a certain selectivity or even targeting. Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 31-Mar-05 Time: 21:33:24 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] refer question
On 01-Apr-05 Peter Schaffter wrote:
> On Fri, Apr 01, 2005, Jorgen Grahn wrote:
>> On Thu Mar 31 23:22:08 2005, [EMAIL PROTECTED] wrote:
>> > Hi.
>> >
>> > I've begun work on adding refer capabilities to mom.
>> > Using the ms refer module as a starting point, I'm
>> > setting mom up to use MLA bibliographic rules.
>>
>> MLA seems to be "Modern Language Association". What kind
>> of status (official or unofficial) does this style have?
>> I have never heard about it or seen it used.
>
> As far as I'm aware, there exists no overarchingly official
> bibliographic style. Numerous institutions and organizations
> have developed their own. Their status is "official" only
> within their respective fields. What works best in a medical
> text may not be appropriate to a dissertation on Shakespeare.
>
> In contemporary North American bibliographies, about five
> styles are "standard", though by no means the only ones used:
>
> AMA (American Medical Association)
> APA (American Psychological Association)
> MLA (Modern Language Association)
> Turabian (from Kate Turabian's _A Manual for Writers of Term
> Papers,
> Theses, and Dissertations_)
> Chicago (The Chicago Manual of Style)
>
> The Modern Language Association has been around for well over a
> century, which gives their dicta concerning style considerable
> clout, though, as with other styles, no official standing.
>
> It's a nice style: neat, clean and flexible. I have some quibbles
> with it, as I do with other styles, but as a "general" style, it's
> by far the one I prefer.
I understand that the MLA style is the general "norm" for
publications in the Humanities, to the extent that many
Humanities journals either strongly recommend it or insist
on it.
To your above list you could also add, for instance, the
AMA (American Mathematical Association) style, used in
JAMA. There are so many! One of the principal merits of
specialised bibliography programs is that they can be
configured (using a syntax-like "style file") to adhere
to a specified standard.
This is one reason I've never much liked using {g|t}roffs
"refer". While it has the feature that you can set up a
database using standard tags, and refer to items in this
in various natural ways in your text, it is distinctly
inflexible when it comes to changing style.
This is not helped by the fact that the implementation
of the formatting is done by specialised macros in whatever
macro package you happen to be using. See for instance
"module ref, Refer support" in s.tmac. In the past I've
had to rewrite this stuff to make it adapt to a different
style!
In the end I switched to a different approach, based on
Tim Budd's 'bib' program, a preprocessor for troff, which
you can configure using "style files". But this seems to
have disappeared from public view since some time ago.
Best wishes,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 01-Apr-05 Time: 23:42:13
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Using pic/groff/gs to produce gif/jpeg
On 11-May-05 David Griffiths wrote: > Hi, I'm new to pic/groff and I've been having some problems > producing either gif or jpeg images using them. The basic > problem seems to be that pic/groff/postscript all have the > concept of a page that they are drawing on whereas I want the > resulting image to have all the whitespace cropped from the > margins. This is to go in a web page so the idea of a page > doesn't make sense. A method which I have often used when using groff (e.g. with 'pic') to create a picture which I want to import as EPS is to simply edit the PostScript file. This, though not fast or automated, works fairly easily. First make your 1-page output in PS using groff. This will come out as suitable for printing on (e.g.) an A4 sheet. Then open the PS file in a PS viewer (I use 'gv' which can be set to re-read the file whenever it changes). Next, open the PS file in a text editor. Groff normally does not put a "%%BoundingBox:" line in the PS file, so the task is to put one in (or, if there is one there already, change it). The format of a ""BoundingBox:" line is %%BoundingBox: llx lly urx ury where llx lly urx ury are four numbers (giving the X and Y coordinates, in points, of the bottom left and top right corners of the page). You will need one of these (preferably at the head of the file amongst all the other "%%" lines you will see there). 'gv' also has a useful little window which shows the (X,Y) coordinates, in points, of the position of the mouse pointer as you move it around; so you can read off suitable values from this window, and this may be all you need to do. Having established in this way what should be reasonable values for llx, lly, urx and ury, insert a "%%BoundingBox:" line of the above form into the PS file, and get 'gv' to re-read it. It should now display solely that part of the page that lies within the BoundingBox. If you're not satisfied, edit the llx, lly, urx, ury until you are. The result is then an EPS file which can be imported into another document, or converted using any standard image format comversion program (I usually use the 'convert' program from the ImageMagick suite, but the GIMP will also do it nicely, for instance). E.g. convert imagefile.ps imagefile.gif or convert imagefile.ps imagefile.jpg The resulting image file will have the dimensions of the BoundingBox. Note: that when importing/viewing/rendering an EPS file, the BoundingBox is a "clipping path" -- anything that lies outside it will not be printed/displayed[*]. This also applies to the conversion into other formats (as above): those .gif or .jpg files will include only those parts of the original which lay within the BB. [*] You can over-ride this in 'gv' which, by default, displys an EPS file in "BoundingBox" mode, as you can verify by seeing "BBox" in the page-format window. If you change this to say "A4" using the drop-down menu, then you will see the whole original. Another resource which can also be used to create an EPS file which includes on the marks on the page is "ps2epsi" (part of ghostscript). This also creates a large "ESPI header" in the output file which is a hex-encoding of a binary bitmap of the page. For the sake of simply having an EPS file for later conversion, you can safely delete all of that stuff (it appears as a large block of "%%" lines near the top of the file). You could also examine the code in ps2epsi and ps2epsi.ps to create new files, say pstoepsi and pstepsi.ps which do not produce this EPSI block. One disadvantage I have found with ps2epsi is that it uses ghostscripts notion of thr font metrics, which may not agree with those used in the groff file, with the result that you may get parts of letters (e.g. descenders) clipped off. Again, I have edited the ghostscript scripts to allow a little extra margin so as to avoid this, but I find that the BoundingBox method described above is better, as well as being more flexible (e.g. you can use it to cut out just the part of the page you want as a separate image file). Hoping this helps, Ted. The disadva E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 11-May-05 Time: 16:20:42 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Spam apparently from list -- again
On 03-Jun-05 Peter Schaffter wrote: > I received six porno-spam emails today, apparently originating from > list members (Werner and Ted). Three yesterday. As before, when > this happened, the attachment is stripped off the email before I > receive it, but the message still comes though. > > Here's a sample envelope+header, in case someone can make use of it. You're not alone! I've been saving these for a while, and the one thing that you can definitely determine from the headers is that a) Almost all of them "helo" as a machine on gnu.org (often monty-python.gnu.org, occasionally others), usually by IP address rather than name. However, this is easily forged, so there's no clue here (except that the originator knows about FQDNs/IP addresses on gnu.org). b) Just about all of them are "Received from 194.2.22.250". This resolves to nat.isep.fr which has also been a source of previous waves of these things. Presumably this is picked up as the IP address of the connecting machine through which these mails are sent. I don't know if this item can be forged. (The above summary covers mails going back to January 2005). The domain isep.fr is the Institut Supérieur d'Électronique de Paris. Since the "nat" in "nat.isep.fr" could refer to a machine on the ISEP network which does NAT (Network Address Translation) it may not be possible to go further back down the line to the true source. I can only think of two suggestions. 1. Does our list have a subscriber from the domain "isep.fr"? If so, then contacting that person may take the matter forward. 2. It could be worth while to contact the Net administrators at isep.fr on the grounds that we are getting persistent (and very specific) spam from that domain. I'm no expert on the inner workings of all this sort of thing, and not being list administrator I can't foind out about #1. So I can only suggest ... ! Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 03-Jun-05 Time: 18:12:16 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] serious pdfroff problems
On 16-Jun-05 Keith MARSHALL wrote: > Mike Bianchi wrote: >> [...] >> So what is the practical fall back? Must shell scripts be written to >> some (undocumented) lowest common denominator of all existing (and >> past and future?) shells? If so, then our problem line should be >> rewritten: >> MATCHTMP=` echo --$OPT | $GREP "^$OPTNAME" ` >> MATCH="$MATCH$MATCHTMP" >> >> I heard many years ago that "it is easier to port a shell than to port >> a shell script". This demonstrates the assertion. > > It is probably doubtful that we can ever achieve true 100% portability > with a shell script; this is why I will probably eventually produce a > C/C++ implementation of pdfroff. Until I find time to do so, I will > endeavour to make the script version as portable as possible. This > means adhering to basic Bourne shell syntax, avoiding constructs which > are known to be problematic. Any POSIX conforming system *should* have > a shell called /bin/sh -- it may be a link to some more advanced shell, > but it is still supposed to be present, and it should be capable of > interpreting standard Bourne shell syntax. Therefore, IMO it is > entirely appropriate that scripts *should* have the #! /bin/sh shebang. > Bash, tcsh, ksh, zsh, etc. are by no means universal -- /bin/sh > *should* be, and has the best chance of providing a portable script > execution environment, provided appropriate portability guidlines > are followed. Be watchful here! When one "command" is a link to another, as for instance /bin/sh -> /bin/bash although the same binary file (/bin/bash) is executed whether one calls /bin/bash or /bin/sh, nevertheless the program *knows* what the call was, and may therefore behave differently in the two cases. Indeed, this seems to be the case for /bin/bash: see the following extract from the output of "man bash" in Linux: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. When invoked as an interac- tive login shell, or a non-interactive shell with the --login option, it first attempts to read and execute commands from /etc/profile and ~/.profile, in that order. The --noprofile option may be used to inhibit this behavior. When invoked as an interactive shell with the name sh, bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the name of a file to read and execute. Since a shell invoked as sh does not attempt to read and execute commands from any other startup files, the --rcfile option has no effect. A non-interactive shell invoked with the name sh does not attempt to read any other startup files. When invoked as sh, bash enters posix mode after the startup files are read. While what is described here as differences between bash invoked as "bash" and bash invoked as "sh" may possibly be harmless in our context, nevertheless it is clear that the two kinds of invocation cause /bin/bash to behave differently. I'm no expert on the details of differences between /bin/bash and /bin/sh -> /bin/bash, still less on differences between bin/someshell and bin/sh -> /bin/someshell, but I think that the possible differences of behaviour need to be borne in mind. Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 16-Jun-05 Time: 17:06:45 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Horizontal rule w/ length a fraction of the page wid
On 15-Jul-05 Michael Smith wrote: > Werner LEMBERG <[EMAIL PROTECTED]> writes: >> To overcome all those limitations I suggest that you say this: >> >> \l'\n(.lu*80u/100u) >> >> avoiding fractional numbers. > > Thanks! That works perfectly (with an apostrophe in place of the > closing paren, which I guess was just a typo, right?). > > So, in general, for computations involving numbers less than one, > is the right way to specify them always as a fraction instead of a > decimal number? How about for fractional numbers greater than one? > > Sorry if I seem clueless -- but the groff info doc and man pages don't > seem to provide much guidance about fractional numbers. At least not > that I could find. Maybe I'm not looking in the right place. It can get ricky. As far as I know, groff still maintains the original troff rule that arithmetic in requests is done in integers (even though you can include fractional numbers as parameters to requests, such as ".sp 0.8m"). Also, while you can force precedence by parentheses, arithmetic is done be evaluating from left to right, so that 1+2*3 = 9 and not 7 To come back to the "fraction of line length" issue, if LL = 6 inches then \n[.l] will return 6*72000 = 432000 (if you're using PostScript). This of course is in "device units". Incidentally, you can always test how things will come out by interpolating "\\n[whatever]" in a test document, so that for instance The line length is \n[.l] units will render as The line length is 432000 units That's already quite a large number, and you have to be careful that your arithmetic does not introduce even larger numbers when you multiply, and cause the arithmetic registers to overflow, so the order of operations can matter. The largest number you can multiply a \n[.l]=432000 by is 4971; after that it overflows and you get 0. For this reason, a conservative version of \l'\n(.lu*80u/100u' is \l'\n(.lu*8u/10u' (\n[.l]*8 is a smaller number thatn \n[.l]*80) or, even safer, \l'\n(.lu/10u*8u' since then you first make a number smaller than the original, and then a bigger one which is still smaller than the original. (Note that "left to right" evaluation ensures that this is what happens). Not that it matters in this case, since you're using small multipliers (less than 4971), but it could if you use large multipliers on bigger numbers. The largest integer you can have in groff is 2147483647 = 2^31 - 1 and you can work out from this why 4971 is the largest multiple of \n[.l]=432000 that you can allow yourself. But -- see below! Another thing to bear in mind is what's going to happen to "lost fractions", i.e. the remainders after division. As far as groff is concerned, 20/7 = 2, the remaining 6/7 being dropped. In the above example this is not going to matter, since 1 point is 1000 units, and even if you wanted a fraction 7/9 of the line-length the result of \n[.l]u/9u or of (\n[.l]u*7u)/9u is going to be wrong by a maximum of 8/1000 points. However, if you do it in the order \n[.l]/9u*7u then you could be out by (7*8)/1000 points. This is still rather imperceptible in real life, but it makes the point, and in a different context it could matter visibly. But there are no absolute rules for all occasions. You have to think about the magnitude of what can happen. Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 15-Jul-05 Time: 18:11:27 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Surface Integral in eqn
On 11-Aug-05 Frank Jahnke wrote:
> Although I'm pretty proficient at eqn, I've never figured out how one
> makes the symbol for a surface integral. This looks like a regular
> integral, but it has an open circle in the middle of it. How might I
> do
> so? Thanks in advance!
>
> Frank
This is a quick reply -- there's a better approach (using the
'special' command in eqn) but it would take me a little longer
to work out details.
Try the following, or some variant of it:
.EQ
sdefine Sint %{type "operator" vcenter \
size +10 {"\Z'\h'0.04n'\v'-0.8n'\D'c 0.5n''\[is]"}}%
.EN
or put the material between ".EQ" and ".EN" in your .../tmac/eqnrc
file.
Example (with the above already defined):
.EQ I
Sint sub S f(x) ~ dS
.EN
Hoping this helps,
Best wishes,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 17-Aug-05 Time: 14:53:08
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Line fragments with .TS and .PSPIC
On 20-Aug-05 Werner LEMBERG wrote: > >> I've been using groff and tbl with FreeBSD 4.2. Whenever I insert >> a table or an image, there seems to be a hard carriage return that >> prints out a line fragment instead of carrying that text to be filled >> with the next line of input after the table. [...] > > Small example, please. > > > Werner I think what frank is referring to is the following sort of thing: using groff -t -Tlatin1 -ms on troff source .LP .2C This text illustrate the problem of inserting .TS centre tab(#); c c. Header1#Header2 .T& l l. _ Entry 1.1#Entry 1.2 Entry 2.1#Entry 2.2 = .TE a table in the middle of a line of text. This text illustrate the problem of inserting a table in the middle of a line of text. gives the output This text illustrate the problem of inserting Header1 Header2 -- Entry 1.1 Entry 1.2 Entry 2.1 Entry 2.2 -- a table in the middle of a line of text. This text illustrate the problem of inserting a table in the middle of a line of text. showing that the output line is broken at the point where the source code has ".TS", while what he would really like is the output = This text illustrate the problem of inserting a table Header1 Header2 -- Entry 1.1 Entry 1.2 Entry 2.1 Entry 2.2 -- in the middle of a line of text. This text illustrate the problem of inserting a table in the middle of a line of text. without having to rearrange the input lines. This could in principle be arranged by diverting the ".TS ... .TE" (possibly with ".TS" and ".TE" re-defined) to a diversion which planted a line trap relative to the current vertical position, so that the tabular stuff was output once the current output-line was completed by filling from the input which follows the ".TS" block. I've tried a few versions of this approach on the above problem, without getting satisfactory results so far (but I confess to finding the "trap" stuff obscure and confusing -- I've often succeeded with it, but without ever being quite sure why!). Maybe others know better ... Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 20-Aug-05 Time: 15:51:56 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Line fragments with .TS and .PSPIC
On 23-Aug-05 Bernd Warken wrote:
>
>
> Jon Snader <[EMAIL PROTECTED]> schrieb am 23.08.05 23:40:11:
>>
>> Perhaps a different macro, or a new argument to .TS to invoke the
>> behavior is what we want.
>
> That's a good idea.
>
> Bernd Warken
I would agree (with the "new argument" idea), though whether it
should be in the "official" ".TS" and ".TE" may be open to debate.
I've had such an arrangement for the 'pic' macros ".PS" and ".PE"
for a long time, but I have put these in my "private" macro set
(loaded after "-ms") so that they over-write the originals.
The background to this is that I find it very useful to use 'pic'
to perform in-line mathematical computations while the document is
being formatted -- 'pic' has a failry powerful numerical engine
built in to it -- so that for instance I can "copy thru" a file of
data through 'pic' commands to compute on it, set troff variables
(registers) with the results using gpic's "command" command, and
then insert these register contents into the document when required
(e.g. in tables).
But in order to do this one needs to encapsulate the 'pic' commands
between ".PS" and ".PE", otherwise nothing will happen, so I re-wrote
these so that ".PS T" with argument "T" (for "tacit") simply bypasses
the normal actions of ".PS" and ".PE" and there is no effect on the
printed page. I.e. ".PS T" and (following such an invocation) ".PE"
are in effect "no op" macros.
The details for this application are:
.de PS
.ie '\\$3'T' \{\
.ds pic*Table T
.\}
.el \{\
.\}
..
.de PE
.ie '\\*[pic*Table]'T' .rm pic*Table
.el \{\
.\}
..
[The reason for "\\$3" is that when 'pic' does its work it computes
a width and height for the graphic and replaces ".PS ..." with a line
".PS ht wid ..."; when there are no "graphic" commands the ht and wid
are both 0.]
A similar approach should work also with the ".TS" and ".TE" macros
to achieve the sort of effect being sought here.
Best wishes to all,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 24-Aug-05 Time: 14:40:25
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] pic: "shaded" problem
On 13-Sep-05 Ole Schoening wrote:
> Dear all,
>
> the following:
>
> .PS
> .fam H
> boxrad=0.15
> box shaded "green" width 1.5 "test test" ;
> .PE
>
> produces no shaded green box (with round corners) but a "normal" one
> without special colours. If I omit the "boxrad" command, then the
> box will be shaded correctly. Typing "box rad 0.15 shaded ..."
> delivers the unwanted result as well. I got these results with groff
> 18.1 under cygwin as well as with gr0ff 19.2 for windows. Does
> anybody have a solution for this problem, how to get round corners
> together with colours?
>
> Thanks in advance,
>
> Ole
This is a horrible tangle. To understand it, you need to look at the
output of pic.
If you feed to pic the commands
.PS
.fam H
boxrad=0.15
box fill 0.5 width 1.5 "test test" ;
.PE
(which does produce a filled box, but filled grey), you will see
that it is drawn as follows:
First, 4 separate filled circles of diameter 0.3 inches are drawn
with "\D'C0.300i'", these being the rounded corners of the box.
Then two filled boxes are drawn (with "\D'P ..."), one having
left and right sides being the straight left and right sides of
the final box, with corners at the leftmost and rightmost sides
of the four circles; the other having top and bottom sides being
the straight top and bottom sides of the final box, with corners
at the topmost and bottom-most sides of the four circles.
In this way, the final box with rounded corners is a superposition
of 6 filled objects: two boxes and four circles.
Finally, the border of this is drawn as follows:
a) four circular arcs are drawn with "\D'a...'", being the rounded
corners;
b) four disjoint straight lines are drawn with "\D'l...'", being
the straight sides.
So far so good. Now comes the crunch. This is in two parts.
A) The 'fill' attribute in pic generates PostScript code where
the fill intensity is set using the PS 'setgray' command.
This has the effect of setting the PS colour space to "gray",
so you cannot get colour fill using 'fill'.
B) The above mechanism of drawing a filled object (e.g. 4 filled
circles plus 2 filled boxes) is only invoked in pic with the
"fill" attribute.
If you feed pic your code
.PS
.fam H
boxrad=0.15
box shaded "green" width 1.5 "test test" ;
.PE
it is not invoked; instead you simply get the outline drawn
in 8 separate parts: arc-line-arc-line-arc-line-arc-line
as when the outline of the filled box is drawn as above.
The result is not a "closed path" in the PS sense, so it
will not be filled anyway.
So, as things stand with pic at the moment, your commands will
not work as you want.
This is is contrast with what heppens if you draw a simple box
with square (not rounded) corners, since this is drawn as a
filled polygon with "\D'P...'".
You can, however, do it with your bare hands, along the same
lines as pic does it for the grey-filled box. You had better
makes this a macro!
For example:
.PS
.fam H
box invis
define colbox {
boxrad=0;
B: box invis width $1 height $2
d = $3 ; h = $2 ; w = $1
circle rad d at B.sw + (d,d) colored $4
circle rad d at B.se + (-d,d) colored $4
circle rad d at B.ne + (-d,-d) colored $4
circle rad d at B.nw + (d,-d) colored $4
box width w height h-2*d with .se at B.se + (0,d) colored $4
box width w-2*d height h with .se at B.se + (-d,0) colored $4
box invis with .se at B.se width 1.5 height 1.0
}
.PE
.fam H
.PS
colbox(1.5, 1.0, 0.15, "green")
"test" "test" at B
.PE
Cumbersome, I know; but it works!
Hoping that this helps,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 13-Sep-05 Time: 18:04:54
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pic: "shaded" problem
On 17-Sep-05 Gaius Mulley wrote: > Keith MARSHALL <[EMAIL PROTECTED]> writes: >> [...] >> Looks like you've discovered a bug in pic's shading code; it doesn't >> seem to work for round cornered boxes, at least on the Win32 platform. >> I've managed to achieve the effect I think you want, with the >> following >> quick and very dirty, and hideously ugly workaround:-- >> >> .PS >> .fam H >> boxrad = 0.15 >> [ box rad 0 width 1.5-2*0.15 shaded "green" invisible >> circle at last box.nw-(0.0,0.15) rad 0.15 shaded "green" invisible >> circle at last box.sw+(0.0,0.15) rad 0.15 shaded "green" invisible >> circle at last box.ne-(0.0,0.15) rad 0.15 shaded "green" invisible >> circle at last box.se+(0.0,0.15) rad 0.15 shaded "green" invisible >> ] >> box at last [].c width 1.5 height last [].height - 2.0*0.15 rad 0 \ >> shaded "green" invisible >> box at last [].c width 1.5 "some text" >> .PE >> >> Perhaps you could develop this into a macro, to work around the bug. >> >> HTH. >> >> Keith. > > Hi Keith, > > well done with the work around. I think this is the way to fix gpic, > internally gpic will have to map a cornered box onto your multiple > objects sequence as there isn't a "cornered box" glyph in gtroff. > > regards, > Gaius As I pointed out earlier, this is in fact how gpic itself deals with round-cornered boxes with the 'fill' attribute. So the mechanism is already there. However, unfilled round-cornered boxes are drawn as a succession of straight lines and arcs (and for good reason -- you don't want to see the "internal" parts of the circles, and the constituent rectangles, in an unfilled box). The bug in gpic, now that it has "shaded", is that it also uses the latter method when drawing a round-cornered box with the 'shaded' attribute, and such an entity is not, as it stands, a closed path, so there is nothing to "fill" with the "currentcolor". Filled circles, and boxes with square corners, are drawn as closed entities (circles via gtroff '\D'C ...', boxes via '\D'P ...'). The simpler immediate fix would be to ensure that when a box has the 'shaded' attribute and rounded corners, the 'fill' method of drawing it is used. However (something I've been pondering for a while), there is in fact a need for a more general "filled object" mechanism in gpic. Already one can draw arbitrary filled polygons (grey or colour) in gtroff using '\D'P ...', though there is no provision in gpic for generating such code except for boxes (unless you insert it "by hand" using 'command' or by enclosing it in text, so that it gets passed through to troff as-is). The sort of thing I have in mind might, in gpic, look like [ arc down rad 1; arc rad 1; line up 0.5 left 0.75; line left 0.5; line left 0.75 down 0.5 ] closed shaded "green" (being the part of a house+garden plan showing the grass lawn). The idea here is that anything within [ ... ] consisting of a series of connected segments, arcs of circles or ellipses, splines, etc. can be made into a closed object with the 'closed' attribute and subsequently shaded (with "shaded" or filled (with "fill"). This could then strightforwardly include the existing special case of filled/shaded boxes with rounded corners, since then the "unshaded" method of drawing these as a sequence of straight lines and arcs would be of such a type, and there would be no need for the special "work-pound" that gpic already uses with "fill". Another feature which is missing (and I'm actually surprised that the original 'pic' did not provide for it) is the rotation of entities. E.g. box with .c at (0,0) rotate 30 for a box rotated through 30 degrees anticlockwise. Howeve, these latter considerations are a longer-term target, since they would involve altering gpic at a much deeper level. As things stand, implementing the above "immediate fix" for round-cornered shaded boxes may be much simpler! Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 17-Sep-05 Time: 12:40:48 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] moving TOC to start
On 26-Sep-05 Jason St Armand wrote: > Hi, > > does anyone have any simple methods for placing the table of contents > at the start of the output file ? > > I have done it manually with Postscript output and should be able to > script that, but if anyone has other suggestions I would appreciate > hearing from them. > > > Many thanks. As Larry and Tadziu have pointed out, there is a variety of approaches to this. All will involve a double pass over the file with groff, however, since the first pass is required in order to ascertain the page numbers, and the second one in order to be able to work at the beginning of the file again. The following toy example (which will work "natively" on Unix/Linux systems; Windows systems might need some modification but I don't know anything about that) shows a very minimal approach. If one wanted to make it more elaborate, there is any amount of scope for developing its elements. The strategy is: 1. Edit the example file "tempTOC.tr" to have the contents below. NB that what is shown as "^A" must be entered as the character Ctrl-A (ASCII code = 1); I use 'vim' as editor, where a control character would be typed in using the keystrokes Ctrl-V Ctrl-A 2. Run groff on it (I'm using ms macros) to generate a file "TOCfile" which will contain the commands to format the TOC, using the groff command shown below at "2." 3. Run groff again, this time to generate the PS file "tempTOC.ps", using the groff command shown below at "3." 1. Contents of "tempTOC.tr" --- .char \[ldr] .\h'1n' .lc \[ldr] .de TOCout .tm .LP .tm .ta 6iR .tm \\$* ^A\\n[PN] .. .LP .so TOCfile .bp 1 .LP Page 1 .TOCout Introduction (page 1) .bp Page 2 .bp Page 3 .TOCout Preliminary Considerations (page 3) .bp Page 4 .bp Page 5 .TOCout Historical Remarks (page 5) .bp Page 6 .TOCout Literature (page 6) .bp Page 7 .TOCout Outline of the Book (page 7) .bp Page 8 .bp Page 9 .TOCout Study Outline (page 9) 2. Command to generate "TOCfile" groff -Tps -ms tempTOC.tr 2>TOCfile >/dev/null 3. Command to generate "tempTOC.ps" groff -Tps -ms tempTOC.tr 2>/dev/null > tempTOC.ps This puts a "TOC" entry into TOC for pages 1, 3, 5, 6, 7, and 9, which appears at the start of the final document. The individual pages 1-9 simply have "Page 1" , ... , "Page 9" on them! Hoping this is useful, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 27-Sep-05 Time: 20:03:53 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] slack4, groff and ps
On 16-Oct-05 mikkel meinike wrote: > Hallow > I have a very small and old laptop computer with a very small and > wonderful linux on it called Basiclinux 3.0. I have for some time bin > looking for some word processing program. That can output good looking > postscript (pdf) file. Abiword won't run on my VGA monitor and TeX is > way to big and complex and I don't even do any mathematic. OK my local > lug advice my to try with groff *roff. So now I am here. First I 'd > like to know if you know if the groff packages that is in Slackware > 4.0 can convert to postscript. (also with the Danish letters æ, ø, > å)(I can install slackware 4.0 packages to Basiclinux 3.0) > > /Mikkel Hello Mikkel, Long ago (1994) I was using a much earlier version of Slackware (Slackware 1.0, which came out in July 1993)! There was no problem with any of the things you want. Groff has always had the capacity to generate PostScript as one of its standard output formats, and various accented characters (such as the Danish æ, ø, å you ask about) were readily available. Back in those days, I was using groff heavily on a very primitive machine (386 4MHz processor, 4MB RAM, 40MB hard drive of which 25MB was assigned to Linux) for a variety of purposes which often required complicated formatting, and also included multilingual work, and groff had all the capabilities required, and there were no system problems. Even prior to that, I was using the "dgj" port of groff to DOS on that same machine, and was still able to do all those things. The only thing I specially did (and indeed have done ever since), since the machine was so weak, was to buy a PostScript printer. With that, the PostScript output from groff went straight to the printer and did not require conversion in the computer to another printer language. Which version of groff is it on the Slackware 4.0? Not that this is of much importance for standard use; though there have been many improvements since then, groff (like troff before it) always had a good repoertoire of capabilities. The specifically Danish characters are standard in groff (along of course with many others) and have names \(ae \(AE for æ Æ \(oa \(oA for å Å \(/o \(/O for ø Ø (which you can also enter as \[ae], \[oa], \[/o] etc. You can also rename \[oa] to say \[ao], \[/o] to \[o/] if you prefer; you can choose your own alternative names). I tend to prefer the "\[..]" form as being more easily readable, especially when proof-reading (since "[..]" marks out the limits od the special name more clearly than "\(.."), as well as "ao", "o/" rather than the "oa", "/o": P\[ao] \[o/]en i s\[o/]en vi kan f\[ao] en s\[ae]t -- \[Ao]lborgs Akvavit med en Carlsbergs \[o/]l is possibly more readable than P\(oa \(/oen i s\(/oen vi kan f\(oa en s\(aet -- \(oAlborgs Akvavit med en Carlsbergs \(/ol to give På øen i søen vi kan få en sæt -- Ålborgs Akvavit med en Carlsbergs øl (but everyone settles on their own preferred details for that kind of thing). Good luck with the installation, and welcome to groff! Please ask to this list any questions you need to get going. Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 16-Oct-05 Time: 22:26:13 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: Printer memory [Was: RE: [Groff] slack4, groff and ps]
On 16-Oct-05 Daniel de Kok wrote: > On Sun, 16 Oct 2005, (Ted Harding) wrote: >> The only thing I specially did (and indeed have done ever since), >> since the machine was so weak, was to buy a PostScript printer. >> With that, the PostScript output from groff went straight to the >> printer and did not require conversion in the computer to another >> printer language. > > This makes me wonder. I am still doing conversion to PCL, either > through grolj4 or Ghostscript, because the printer memory > requirements are lower for printing PCL than PS (according to HP). > Does anyone have some advise on what amount of printer memory would > be OK for doing direct PS printing without too many printing delays? > I have a LaserJet 5. > > -- Daniel For most usage, less than you might think! For instance, if your document uses only the "standard Adobe character sets", which you can assume will be already installed on the printer (if it uses genuine Adobe PS, like HP's PS printer), or mapped to the manufacturer's proprietary emulations (like many Brother printer), then the printer "dyamic" memory required is only what is needed for the PS code for the number of characters on one page -- say 30KB for a 2-page document with about 5K characters on each page. It gets more demanding if you have to embed font definitions, since these have to remain stored -- or be re-embedded in each page -- throughout the document. It gets even more demanding if you embed large bit-mapped graphics objects. Very occasionally I have had memory overflow in extreme cases of the latter. Mostly, however, I have no problems and no noticeable delays. For instance, my current HP 1300 laserjet has 16MB total RAM, of which a large chunk is reserved for the page-image, leaving (according to printer status page) only 5.6MB "available". Nevertheless with this I can print the PS file obtained by scanning an A4 sheet at 300dpi greyscale (a 12MB PS file). The time taken between initiating the sending to the printer, and output of the printed page, is just under 4 minutes (much of which is taken up by simply transmitting the bytes along the parallel-cable). On the other hand, printing the PS file for a text document prepared by groff is almost instantaneous -- about 10 seconds for the printer to wake up, and print the first page, then about 4 seconds per page after that. The issue about PS vs PCL is that with PCL graphics data arrive at the printer already "rasterised", so the printer does not need to "remember" so much before it knows what to do. So it could matter in marginal cases. Hoping this helps, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 16-Oct-05 Time: 23:58:49 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] PS and "page background"
s why it needs to go into "LH", if you are
using this mechanism, since while the corresponding
part of the footer, "LF", will be printed on every
page including the first, the string \*[LF] would
over-print the text, which might not be what you want).
NOTE: the coordinates, rotation and scaling in the
PS code above take account of the fact that when groff
generates its own PS code, it inverts the y-axis, i.e.
measuring distance from the TOP of the page, while
raw PS measures from the BOTTOM of the page. Compare
example D below.
B. Case of (4) above. At the start of your groff source
file, enter a PS definition.
\X'ps: def /wmk {gsave \
/Times-Roman findfont 96 scalefont setfont \
170 508 moveto 315 rotate 0.85 1 -1 scale \
setgray (D R A F T) show \
grestore} def'
(Note the slight difference from the preceding: "exec"
replaced by "def").
This defines, once and for all, a PS procedure called "wmk".
So, every time you have
\X'ps: exec wmk'
in your groff source file, the procedure "wmk" will be
executed.
So, for one page only, a groff source file
\X'ps: def /wmk {gsave \
/Times-Roman findfont 96 scalefont setfont \
170 508 moveto 315 rotate 0.85 1 -1 scale \
setgray (D R A F T) show \
grestore} def'
\X'ps: exec wmk'
.LP
This is some text which we want to print out with a
\(lqDRAFT\(rq `watermark' background.
.br
This is some text which we want to print out with a
\(lqDRAFT\(rq `watermark' background.
.br
[about 80 of these]
will first print "D R A F T" as before, and then overprint
the text. To get it on every page, you either need to repeat
the "\X'ps: exec wmk'" each time, or else define this as the
"LH" string but still put it explicitly on the first page.
C. Case of (2) above (\X'ps: import ... ') using an
external EPS file.
First create the same code as am EPS file. This means working
out what the bounding box should be, and also including the
canonical first line. The file watermark.eps contains:
%!PS-Adobe-2.0
%%BoundingBox 0 0 594 765
/Times-Roman findfont 96 scalefont setfont
170 157 moveto 40 rotate 1 1 scale
0.85 setgray (D R A F T) show
showpage
Now have
\X'ps: import watermark.eps 0 0 594 765 594000 765000'
as the first line (before any text starts) and define
it as the "LH" string for subsequent pages, as above.
NOTE that the coordinates etc. in this PS code are changed
from those in example A, since this code has to be defined
relative to the default PS coordinate space where vertical
distance is measured from the BOTTOM of the page.
D. Case of (1) above, using PSPIC. PSPIC is best suited
for putting diagrams and pictures into text as illustrations,
since its use is tightly bound to the current printing
position. Also, since the printing position moves on after
PSPIC has been used so as to lie below the graphic, it is
awkward to use it for a watermark (where you would have to
move back to the top of the page before printing the main
text).
Therefore use methods 2,3 or 4, as illustrated in A, B and C,
for things like watermarks.
However, if say you are a property agent and have a digital
photo of house you are selling, first convert this to EPS
(on Linux you can use the 'convert' program in ImageMagick
if your system will support it). so that you have a file
house.eps
Then you can write your document:
.LP
.ce
\f[BI]\s[20]Desirable Residence at Øresund\s0\fP
.sp
.LP
This attractive house near the beach at Øresund ...
[some tempting stuff]
.PSPIC house.eps 152c
.ce
\fBFrontal Elevation of the Property\fP
[lots more temoting stuff]
which will cause the picture of the house to occur at that
place in the document [you may have to take special measures
if there is not room for it at the bottom of thepage],
following the text [some tempting stuff], centred, and of
width 12cm. The text [lots more tempting stuff] will follow
on below the picture.
Hoping this outline is helpful to get you started.
All best wishes,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 17-Oct-05 Time: 13:36:13
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] PS and "page background"
On 17-Oct-05 Miklos Somogyi wrote: > [...] > If you are serious about learning PS, try to get a copy of > the first edition of Adobe's PostScript Reference Manual. > Unlike later editions it is not intimidating and you can > study it to good effect at a long weekend. > It is out of print but there are many second-hand shops > (at least in the US) that sell "nearly as new" copies > for $2 or $3. Plus postage ... :-) It is a worthwhile investment. To this I would add PostScript Language Tutorial and Cookbook" also written by Adobe Systems Inc., and published by Addison-Wesley. This leads you in from the beginning, giving examples of tiny PS programs which do not only basic but also interesting things and which really work! It also explains the details of how PS works as a programming language -- the biggest implementation of a Reverse Polish I've encountered, the next biggest being Forth (and the third biggest being an HP-85 calculator I used to own). It's a very good starting point if you are new to PS, and you can use the examples as templates for your own effects. Best wishes to all, Ted. -------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 17-Oct-05 Time: 15:16:21 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
On 18-Oct-05 Werner LEMBERG wrote: > >> We had a discussion on this list a few months ago, that if anyone >> had done a WYSIWYG front-end for groff years ago, it would be more >> viable for the masses. Sigh. > > Well, Larry and Ted showed scripts which can do that. We should > probably add such a thing to groff. Volunteers to prepare a patch? > Be warned that I need a copyright assignment (from those who haven't > assigned one already) in case the added code is longer than around 15 > lines. Re my script (which I've posted a couple of variants of): if I've posted anything ever, it's up there for anyone to use as they please! As far as formal copyright is concerned, I'm not sure of the implications. That script is basically the one which I use all the time, with some strictly local details stripped out; but it's still somewhat specific to the way I use it. As a general resource, it would need some "generalisation". As it stands, people can see how it works. There's a little bit of intricacy at its core, which is the key to how it works, but the general purpose of posting it was that others can make whatever changes they need to adapt it to their own way of doing things. For what it's worth, it is as much yours as it is mine. But once such a thing gets a "copyright assignment", does that then put it into the grip of the GNU GPL or the like? With the implication that if anyone makes a change and then passes on the revised version, there must be the canonical reference to the original sources or traceback thereto? Etc.? If there are such implications, then I'd be a bit uneasy; that seems like overkill! While I'm a devotee of the principles of Free Software, and for all that I recognise the protection that GPL etc. provide for these principles, I'm also a devotee of Freedom From Bureaucracy! (This also connects to UTP, which Meg mentioned, and I'll post separately about that when I've had a bit more think ... ). Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 18-Oct-05 Time: 09:26:21 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
On 19-Oct-05 Miklos Somogyi wrote: > [...] > If troff and Co is to survive, then changes are necessary. > No use to tell managers to lean on engineers to use proper tools. > They would rather lean on someone who wants something else, > not a PC. > > To close it with an appropriate joke: > > The Zen master bought a $2 hot dog and paid with a $10 bill. > He was waiting and waiting for his $8. The vendor looked-up > and realized what was going on in his mind, but said to him: > > Hey, you are a Zen master. You know that change must come > from within... > > Miklos Very good, Miklos! I have to sadly agree with the assessment of the practical situation. What computers "can do" is nowadays defined, for the vast majority of users (maybe over 95%) by what has been wrapped in the GUI by the GUI designer (as well, of course, as by the intrinsic limitations of the underlying software). It is like what is also a reasonable approximation to real life: that the places you can be at are those that you can reach in a motor car, and your diet is what you can take off the racks in a motorway service station. And you only rarely walk. Leaving only the mad fringe who go out and climb mountains, sail boats, catch their own fish, grow and cook their own food, ... Regarding the use of keyboard/command-line versus mouse/GUI, I close in turn with a joke (not mine, though: it was said by Charles Curran of the UK Unix User Group) "I can touch-type, but I cannot touch-mouse" Best wishes to all, Ted. ------------ E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 19-Oct-05 Time: 09:43:06 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Using groff as one's main WP/TP
On 20-Oct-05 Robert Marks wrote: >> However, I think that using groff to write your webpage, or as a >> front end for various document formats, is probably misdirected. >> DocBook, word processors, LaTeX (in some cases), and so on are much >> better suited to these various tasks. > > I use groff for letters, academic papers, and class overheads (with the > mpresent package). I've been using *roff since the days of nroff and > daisywheel printers, i.e., 1978. Am I alone? Well, you're tempting everyone to put their acitivites into the pot! I've used *roff since starting with Unix in the early 80s, and during a period with DOS alone was using groff and WordPerfect-5.1 in parallel (interesting that in particular WP51's equation editor was very reminiscent of eqn). I basically use groff for everything. I've typeset a couple of books with it (not authored by me), to make camera-ready copy, and more that a couple of PhD theses (for friends or students, for the sake of good appearance); the theses in particular typically had lots of equations and figures, which would always come out beautifully. Presentations, too. And I wouldn't bother with any special package. Well laid-out screen-sized pages projected from the computer as PS or PDF files works fine. And with PDF you can plant PDFmarks in your groff which become cross-links or active links in the presentation, so you're up in "powerpoint land" only with much more class -- and you have not had to fight off the coercive influence of the PPt program itself! The ability to fine-tune formatting in groff still makes it nearly if not really unique. I recall one project which involved making camera-ready copy for some chapters of a book, the other chapters of which had already been prepared in WordPerfect. So the task was to closely emulate every detail of the existing style. Groff came up to the mark! Fundamentally my view of groff is that it enables you to place arbitrary marks in arbitrary positions. With that in mind you can envisage any task. Of course it may take a while to find out how to achieve that arbitrary placement, but it's in there somewhere. And this, I think, is where the generation gap begins to show. Those of us who were doing that kind of work pre-1990 found out that groff/troff was the best show in town at the time (TeX was only just emerging). So if we wanted to do some particular thing, we worked out how to do it, and so on; and thus over the years (literally) aquired fluency. For quite a while after TeX emerged, froff could still out-TeX TeX on some fronts -- even as late as 1996-7 I recall groffing tables and diagrams for colleagues who couldn't quite get TeX to do what they wanted. The generation who have started their document work since the late 90s, however, have a different view of things, it seems. Software became easier to use for basic formatting, so the "programming language" nature of groff, inherent in doing good work with it, became a put-off. Along with this came a culture that people's standards of layout were what software like Word gave them. Sadly, I'm inclined to lump in with this the later versions of WordPerfect subsequent to its Windowsization. One thing WP lost in this transition was the "printer editor", which was a major element in customising layout in WP51. Groff, along with TeX, will I hope still be what people will choose who have a proper eye for style, layout, formatting, readability, and all the key elements of good typesetting. Especially when they want to do something "difficult" ... Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 20-Oct-05 Time: 18:21:53 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] RE: PS and "page background"
On 21-Oct-05 Manas Laha wrote: > Ted Harding's post on the above topic a few days ago was great. > > Not only did I learn about how to print a page background (something > that I occasionally wanted to do but didn't know how), but his several > examples of embedding Postscript code in a groff document has shown me > new ways to use groff. > > Many thanks, Ted! > > - Manas Laha Thanks, Manas! Just sharing the fruits of some long experience ... We old-timers seem to be starting to let it all hang out. (I think Meg may have triggered it). Miklos is asking for statistics ... he says he's (70 - x) (0 < x < 1), and I'm 2 behind him; and so on ... This is getting archaeological! I think the big break-through for general use came with the Apple Laserwriter in the very early 80s: the first "commodity" PostScript printer! Once people had that, and troff could generate PS, the last barriers were down. I'm full of admiration for the folks who grappled with the photo-typesetters -- sort of "optical daisywheel", I suppose. And I can remember from the early 70s a friend drafting her PhD and papers on a teletype using runoff. Strength of character there. As I said earlier, in those days one realised that troff had all the capabilities you might want, if only you could work out how to make them act. As needs arose, that is what we did. Regarding the "man pages" issue, there was a period (mid-90s to maybe 2001-2) following the take-off of Linux when groff somewhat sank into obscurity. Because it is essential for formatting Linux man-pages (just as it was for the original Unicx man-pages), a general view spread, amongst people who should have known better, that (as once expressed on a Linux User Group list): The only function of groff is to format man pages to which I replied I respectfully disagree (aka bollocks) followed by an outline of what one really can use it for. Happily perceptions are moving away from this, and back to the proper view. When all is said and done, the fact that troff was capable of general-purpose document formatting is what saved Unix from being dropped as a project, pre-1970! Best wihes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 21-Oct-05 Time: 11:35:47 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
On 22-Oct-05 Werner LEMBERG wrote: >> > . Documentation of GNU projects should be in texinfo format. >> >> Err, there are lots of so-called GNU projects that aren't documented >> in texinfo. > > This is true but very unfortunate IMHO. It isn't very difficult to > write a texinfo file, and there are many benefits to do that. I would like to dissent (partially) from this. Granted, writing detailed explanations, examples, etc. in a texinfo file is a good thing to do, and it's a valuable resource when you need such things. However, I have always regretted, even resented, GNU's transition from "man" to "info" for basic reference. For people who are accustomed to them, man pages are easy and quick to use, for the most part. Admittedly, the terseness of some classic Unix man pages, and the not infrequent need to cross-reference between several such pages, could make it a trying exercise too. But, nowadays, many GNU man pages are mere stubs, when they used to be full summaries, and the reader is told to read the info document. For all the wonderful opportunities that the GNU project has opened up for the world, and its impeccable adherence to freedom of software, nevertheless there is something of "1984" about GNU. For instance, though are still far from succeeding, I suspect that the GNU Thought Police really want everyone to use EMACS. And it's not difficult to see hints of that in texinfo! Where texinfo itself is concerned, however, it seems they are a bit closer to dominating how users think and work. I don't -- and won't -- use EMACS: I can't stand it! I do, and want to, use vim. I like, and want to have, good man pages which list all the essentials of the behaviour of commands. I rarely want to get into the labyrinth of a texinfo document (though I'm pleased it's there I need the more discursive information it contains). So I'm not in favour of any trend which would take away what I like and want. Man pages have a good function, and would better fulfil that function if comprehensively written. This should not clash with info documents, which better fill a different function. And there is plenty of scope for an auxiliary collection of documentation in a variety of formats to explain and illustrate the software, and to guide users. The preferences stated above are mine. I don't expect others to share them: they should be free -- and enabled -- to adopt their own preferences. Likewise, so should I be (and anyone else who happens to share mine). Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 22-Oct-05 Time: 12:40:59 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
On 22-Oct-05 Werner LEMBERG wrote: >> > This is true but very unfortunate IMHO. It isn't very difficult >> > to write a texinfo file, and there are many benefits to do that. >> >> However, I have always regretted, even resented, GNU's transition >> from "man" to "info" for basic reference. > > I *fully* agree. It seems that you've got the wrong impression that I > don't like man pages, or that I favour texinfo over man. > > man page are a perfect tool for basic documentation, and I'm always > disappointed if `man foo' doesn't work. > >> But, nowadays, many GNU man pages are mere stubs, when they used to >> be full summaries, and the reader is told to read the info document. > > This is sadly true -- note that I've always invested *a lot* of time > to have the man pages as concise as possible, taking the extra burden > to hold groff.texinfo in sync. Werner, please excuse me if I gave the wrong impression! I am not criticising the man pages for the various components of groff, which are now excellent (as those of us, who remember drawing up concordances because "only differences from Unix troff are documented", will surely agree!). > Hopefully, all users here have taken a look at groff(1), reading the > `SEE ALSO' section which brings you to, say, groff(7) or to > groff_man(7). > >> For instance, though are still far from succeeding, I suspect that >> the GNU Thought Police really want everyone to use EMACS. > > I don't think so. > >> And it's not difficult to see hints of that in texinfo! > > What exactly do you mean? Basically the repertoire of keystrokes, which seem to resemble EMACS ones; OK if you remember them, which I don't (apart from SPACE and BS). However, to be fair, it does seem that 'info' has become more transparent over the last year or two than it used to be. >> I rarely want to get into the labyrinth of a texinfo document >> (though I'm pleased it's there I need the more discursive >> information it contains). > > If a texinfo document appears as a labyrinth, it is badly written, or > rather, it has a bad structure. Sadly, groff.texinfo has similar > problems, but I don't have the time to get a better structure, and > probably, I'm too involved and too bad at writing documentation to fix > that properly. Again, and help is highly welcome -- it basically > means shifting the chapters and sections, without even editing > anything. Again, I'm not particularly criticising groff.texinfo, which does seem to be pretty good as far as I can judge it. It's more to do with the general "access route" into info. I confess to having the same sort of problem with GUI menus -- it requires remembering, or groping for, a pathway to what you want; whereas my way of thinking about composing a task is more on the lines of "You, you, and you! Line up and do that job." Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 22-Oct-05 Time: 14:23:38 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] XML and groff as frontend
On 22-Oct-05 Zvezdan Petkovic wrote: [...]> > That's also a nice example of how painful is writing in XML. > You use a totally different tool (Vim) to help another tool that's > supposedly made to help you with XML (FrameMaker). > > Also, sections and lists are the least of my issues with XML. > Paragraphs like this one are the problem (quite frequent when writing > about computing): > > Use either cp -a or > cp -Rdp when copying, to preserve as much of > the original attributes of an application. > Then in rootfs/sbin make a > hard link from mke2fs to > both mkfs.ext2 and > mkfs.ext3. > > If you count the characters in markup elements, they'll come quite > close to the number of characters in the real content of the > paragraph. I did the markup after writing, because the number of > interruptions of the thought process is mind-boggling otherwise. Well, if you're using vim ... First enter the following (in command mode) to define abbreviations: :ab :ab :ab Then, in insert mode, enter: Use either cp -a/c or cp -Rdp/c when copying, to preserve as much of the original attributes of an application. Then in rootfs/sbin/f make a hard/e link from mke2fs/c to both mkfs.ext2/c and mkfs.ext3/c. (which I did by copy&paste from another window which originally contained your original above, edited into the above form by :.,$s//cp -a or cp -Rdp when copying, to preserve as much of the original attributes of an application. Then in rootfs/sbin make a hard link from mke2fs to both mkfs.ext2 and mkfs.ext3. [Sorry, just flaunting my favourite editer]. I agree totally about the interruption to thought, though, and I don't think my trick would help much on that front (and in fact setting it up was made easy by having the final form in front of me; not so easy to do it "blind"). On the other hand, using simple groff macros for the font switches doesn't cause me any problems at all .. I wonder why ...? Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 22-Oct-05 Time: 23:45:44 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] XML and groff as frontend
On 23-Oct-05 Zvezdan Petkovic wrote: > On Sat, Oct 22, 2005 at 11:45:50PM +0100, Ted Harding wrote: >> Well, if you're using vim ... > > I do. > >> First enter the following (in command mode) to define abbreviations: >> >> :ab > [cut a lot of good advice] > > You mean something like > > iabbrev byiwi<ea> \ fileref="" > \format="linespecific">pa>-$h > >:-) Yes I did! -- But the full depth was beyond me :-) > I have a full Vim plugin that contains not only the most frequently > used abbreviations, but also a function to enclose words in an > arbitrary chosen DocBook XML element chosen from a small narrow > buffer that opens on the right side of my Vim window with a list > of all DocBook elements. > It doesn't sing or dance though because I stopped working on it the > minute I lost interest in editing more DocBook documents. >:-) > > Best regards, > > Zvezdan Petkovic But thanks for showing the sort of thing that really is possible. Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 23-Oct-05 Time: 09:42:14 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Foxit PDF Reader
On 23-Oct-05 Clarke Echols wrote: > I downloaded the Foxit PDF Reader and tried it out on some > slides I'm creating. The edges on circle lines look rough. > Acrobat is much cleaner. > > I hear about the "Acroread" reader. Is that different from > the Acrobat Reader? I see no reference to it on Adobe web pages. > > Clarke For the record: "Acrobat Reader" is the name (assigned by Adobe) for their program which displays PDF files. This name is intended for reference in text, conversation, etc., as in "Open this file using Acrobat Reader" or "Download Acrobat Reader from here". When you install it, the name of the binary is "acroread" (at least on Linux). In a Windows-98 partition, however, I have found ./Program Files/Adobe/Acrobat 4.0/Reader/AcroRd32.exe so it looks as though the binary may be called "AcroRd32" in Windows. Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 23-Oct-05 Time: 19:35:20 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Drawing filled circle segments
On 25-Oct-05 Clarke Echols wrote: > > I need to use drawing requests (\D'...') directly (without > using PIC) to make pie-chart segments that can be filled with > color. > > I have no problem getting filled boxes and polygons, but I > have not discovered how to draw two lines with an included > angle, then connect the two outside ends with an arc whose > radius is centered at the vertex of the two lines. > > Any suggestions? I must be missing something very obvious... > > Thanks, > > Clarke I don't think you are, Clarke! What you want to do does not, as far as I know, fall withing the repertoire of \D'...'. A similar question was discussed recently on the list (Sep 13-18) regarding producing a "shaded" box with round corners. As was pointed out by Keith Marshall and me, pic's approach to this involves drawing several shaded entities -- two rectangles and four circles -- because the method of drawing a simple box with rounded corners is to draw 4 lines and four arcs with \D'...', and not "closing" the resulting path. As a result, PostScript cannot shade it. The same would apply to your pie segments. And I can't think of a clean way to make one of these in a similar way (especially if you want to place them side by side in a pie chart). The only entities that \D'...' (and therefore also pic) can shade are polygons (\D'P ...'), ellipses (\D'E ...') and circles (\D'C ... '), because these are also intrinsically closed entities in PostScript. As I said before, pic needs an attribute "closed" for entities drawn with line and curve segments, so that these can be filled in PostScript. I can only think of setting up a little stanza in PostScript which would be invoked to draw the necessary item, though making sure that it was placed at the roght point and at the right angle would need careful watching. I will try to invent one, but probably others will beat me to it! Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 25-Oct-05 Time: 21:16:03 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Drawing filled circle segments
On 28-Oct-05 Werner LEMBERG wrote:
>
>> I need to use drawing requests (\D'...') directly (without
>> using PIC) to make pie-chart segments that can be filled with
>> color.
>
> This isn't possible directly in groff (nor it is possible directly
> with pic). It is not too difficult to write a macro which constructs
> the segment itself with \D'l...' and \D'a...', but there's no way to
> fill it. The only solution is to approximate the segment with a
> filled polygon.
>
> Let's see what Ted will cook :-)
>
>
> Werner
Well, here's a skeleton with an example of use. Basically, as it is,
you invoke in-line it with
\*[wedge radius(pts) Red Green Blue Angle1 Angle2]
and carry on from there ... I was toying with the idea of building
a full macro out of this, but then I thought that different people
will want to arrange things in different ways, so provided you
have the basic "wedge" building-block you can build your own.
And of course you can tweak its functionality.
Here's the sample troff code (".LP" from ms macros; vary to taste):
\X'ps: def \
/wedge { gsave \
currentpoint translate 1 -1 scale \
/ang2 exch def \
/ang1 exch def \
/B exch def /G exch def /R exch def \
/rad exch def \
R G B setrgbcolor \
newpath \
0 0 moveto \
0 0 rad ang1 ang2 arc \
closepath \
fill stroke \
grestore \
} def
.ds wedge \Z'\X'ps: exec \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 wedge''
.LP
\&
.sp 1i
This is a line with_\h'0.5i'\
\*[wedge 36 1.0 0.0 0.0 000 045]\
\*[wedge 36 0.5 0.5 0.0 045 100]\
\*[wedge 36 0.0 1.0 0.0 100 170]\
\*[wedge 36 0.0 0.5 0.5 170 250]\
\*[wedge 36 0.0 0.0 1.0 250 360]\
\h'0.5i'_in the middle of it.
.sp 1i
That was a line with a bar-chart.
Best wishes to all,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 28-Oct-05 Time: 14:49:05
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Drawing filled circle segments
[OOPS] On 28-Oct-05 Ted Harding wrote: > [...] > .LP > \& > .sp 1i > This is a line with_\h'0.5i'\ > \*[wedge 36 1.0 0.0 0.0 000 045]\ > \*[wedge 36 0.5 0.5 0.0 045 100]\ > \*[wedge 36 0.0 1.0 0.0 100 170]\ > \*[wedge 36 0.0 0.5 0.5 170 250]\ > \*[wedge 36 0.0 0.0 1.0 250 360]\ > \h'0.5i'_in the middle of it. > .sp 1i > That was a line with a bar-chart. Oops -- I meant "pie-chart" !! Ted. -------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 28-Oct-05 Time: 14:54:27 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Drawing filled circle segments
Another Oops! The end of the \X'ps: def' was missing its closing
quote in my first post (not that it seemed to spoil it!).
Here is the code again.
\X'ps: def \
/wedge { gsave \
currentpoint translate 1 -1 scale \
/ang2 exch def \
/ang1 exch def \
/B exch def /G exch def /R exch def \
/rad exch def \
R G B setrgbcolor \
newpath \
0 0 moveto \
0 0 rad ang1 ang2 arc \
closepath \
fill stroke \
grestore \
} def'
.ds wedge \Z'\X'ps: exec \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 wedge''
.LP
\&
.sp 1i
This is a line with_\h'0.5i'\
\*[wedge 36 1.0 0.0 0.0 000 045]\
\*[wedge 36 0.5 0.5 0.0 045 100]\
\*[wedge 36 0.0 1.0 0.0 100 170]\
\*[wedge 36 0.0 0.5 0.5 170 250]\
\*[wedge 36 0.0 0.0 1.0 250 360]\
\h'0.5i'_in the middle of it.
.sp 1i
That was a line with a bar-chart.
Ted.
------------
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 28-Oct-05 Time: 16:38:14
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Drawing filled circle segments
Here is a variant where the sectors are outlined with
thin black lines, if you prefer that.
\X'ps: def \
/drawwedge { \
newpath \
0 0 moveto \
0 0 rad ang1 ang2 arc \
closepath \
} def'
\X'ps: def \
/wedge { gsave \
currentpoint translate 1 -1 scale \
/ang2 exch def \
/ang1 exch def \
/B exch def /G exch def /R exch def \
/rad exch def \
R G B setrgbcolor \
0.01 setlinewidth \
drawwedge \
fill stroke \
0 setgray drawwedge stroke \
grestore \
} def'
.ds wedge \Z'\X'ps: exec \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 wedge''
.LP
\&
.sp 1i
This is a line with_\h'0.5i'\
\*[wedge 36 1.0 0.0 0.0 000 045]\
\*[wedge 36 0.5 0.5 0.0 045 100]\
\*[wedge 36 0.0 1.0 0.0 100 170]\
\*[wedge 36 0.0 0.5 0.5 170 250]\
\*[wedge 36 0.0 0.0 1.0 250 360]\
\h'0.5i'_in the middle of it.
.sp 1i
That was a line with a pie-chart.
Best wishes,
Ted.
------------
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 28-Oct-05 Time: 17:04:29
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Drawing filled circle segments
On 28-Oct-05 Werner LEMBERG wrote:
>
>> Well, here's a skeleton with an example of use.
>
> *Very* nice!
>
>> Basically, as it is, you invoke in-line it with
>>
>> \*[wedge radius(pts) Red Green Blue Angle1 Angle2]
>
> Aah, you use the new string syntax with arguments! This means that
> you need at least groff 1.18.
Indeed! Thanks for the reminder.
One can, of course, encapsulate the parameters in a macro.
Thinking about it, I have the idea that one can define the
wedge-drawing strings in a macro and then invoke them when
required. That way, it's classic groff.
Example (using the PS definition which give the segments
with black borders):
\X'ps: def \
/drawwedge { \
newpath \
0 0 moveto \
0 0 rad ang1 ang2 arc \
closepath \
} def'
\X'ps: def \
/wedge { gsave \
currentpoint translate 1 -1 scale \
/ang2 exch def \
/ang1 exch def \
/B exch def /G exch def /R exch def \
/rad exch def \
R G B setrgbcolor \
0.01 setlinewidth \
drawwedge \
fill stroke \
0 setgray drawwedge stroke \
grestore \
} def'
.de mkwdg
.ds sname \\$1
.shift
.ds wedge.\\*[sname] \Z'\X'ps: exec \\$* wedge''
..
.LP
\&
.sp 1i
.mkwdg 01 36 1.0 0.0 0.0 000 045
.mkwdg 02 36 0.5 0.5 0.0 045 100
.mkwdg 03 36 0.0 1.0 0.0 100 170
.mkwdg 04 36 0.0 0.5 0.5 170 250
.mkwdg 05 36 0.0 0.0 1.0 250 360
This is a line with_\h'0.5i'\
\*[wedge.01]\
\*[wedge.02]\
\*[wedge.03]\
\*[wedge.04]\
\*[wedge.05]\
\h'0.5i'_in the middle of it.
.sp 1i
That was a line with a pie-chart.
It's basically the same principle as before, but here the macro
.mkwdg name rad R G B ang1 ang2
creates the string
\*[wedge.name] -> \Z'\X'ps: exec rad R B G ang1 ang2 wedge''
So even the dinosours now have pie-charts! (though my professional
statistician's eye does not consider that pie-charts are always a
good way to present information (despite what the management
might think).
As a further thought, given that the building-block which the
user defines is a parametrised wedge, it occurred to me that
this allows you to present "two-dimensional" information in
the pie-chart.
As an example, suppose we have data on the 5 employees of
a small business, their salaries, and also the profit they
directly generated, as follows:
SalaryProfit
-
Red 45,000 120,000
Khaki55,00080,000
Green70,000 200,000
SeaGreen 80,000 250,000
Blue110,00050,000
=
(colour-coded to protect their identites, though "Blue" is
the Company Director)
and we decide to present this as a pie-chart in which the
angle of the sector is proportional to the salary (i.e. the
cost to the company), and the area of the sector is proportional
to the profit generated.
If we take "Green" to have the "standard" radius of 36p
as above, this then gives the following equivalent in
degrees angle and points radius (rounded):
Degrees Radius(pt)
Red45 35
Khaki 55 26
Green 70 36
SeaGreen 80 38
Blue 110 14
we can then have (append this to the above troff code so as
to get the PS definitions):
.LP
\&
.sp 1i
.mkwdg 01 35 1.0 0.0 0.0 000 045
.mkwdg 02 26 0.5 0.5 0.0 045 100
.mkwdg 03 36 0.0 1.0 0.0 100 170
.mkwdg 04 38 0.0 0.5 0.5 170 250
.mkwdg 05 14 0.0 0.0 1.0 250 360
This is how the personnel performed:\0\0\h'0.5i'\
\*[wedge.01]\
\*[wedge.02]\
\*[wedge.03]\
\*[wedge.04]\
\*[wedge.05]
which just about sums it up ("Red" is the guy who gets to prepare
this stuff; and he's leaving for a better job soon ... ).
Of course, if you think the impact should be different, you can
re-calculate the radii for yourself according to a different rule.
Best wishes to all,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 28-Oct-05 Time: 20:17:28
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Groff wiki?
On 28-Oct-05 Robert Goulding wrote: > With all the discussion recently on the need for groff documents > teaching fundamentals and techniques - and with all the terrific > stuff that is frequently posted to this list (most recently, > Ted's solution for pie-graphs), it seems to me that a wiki for > groff would be very useful. We could: > > - put all the man pages and info docs up on line in HTML form for > browsing > > - post guides for all the macro packages > > - archive all the tricks, techniques and solutions to unusual > problems that have been posted here > > and, of course, since it is a wiki, allow anyone in the community > to post interesting code or techniques that they use, for permanent > reference and reuse. I'm sure there are many people out there how > are doing remarkable things with groff - it would be great if they > could be shared more widely. > > I don't know much about setting up or hosting a wiki, but would > certainly want to contribute, as I think many others on the list > might as well. I have a unwieldy directory of code-snippets I've > culled from the mailing list from the last couple of years - it > would be good at least to put them in some sort of order! This is a good idea! I've often thought of putting such things somewhere, for people to consult or to incorporate into more systematic documentation about different aspects of groff. I've only lately become properly aware of the 'wiki' idea, and rather like it in principle. In so far as it remains the sort of haven where like-minded people of good will can wander in, take note of what they like, and leave their own good things for others, it seems a straightforward and excellent solution. I'd also sound a note of caution, however. My local Linux User Group ( http://www.alug.org.uk ) has had a wiki going for some months now, and it has unfortunately been vandalised on occasion, leading to the result that you will see if you now visit the above site and click on "Contrib Area"; and also to some acrimony on their mailing list, since there are issues about who should be responsible for what when it comes to maintenance, security, and so forth. This risk is bound to be present for a "wide open wiki". I don't know the best solution to this problem. One could be that anyone who wants to contribute can get a passowrd from "someone in charge", as a "trusted contributor", which would then enable them to enter the wiki and edit away. This would perhaps place the least load on whoever was "hosting" it. Another, somewhat at the other extreme, would be that it is a "moderated" wiki -- people can submit contributions, which would normally be nodded through. However, there is potentially so much good stuff out there amongst all our archives that this could lead to bottlenecks, and intolerable load on moderators. In any case, it might be a good idea (though I don't know if this can be readily arranged on a wiki) that the person who makes a contribution should be the only person with "write permissions" (apart from the wiki administrators). Not that I'm trying to be restrictive for the sake of it here -- but it occurs to me that someone reading a piece might think they can "improve" it, and promptly do so; with the effect of spoiling it, or worse. There should be some control, by people who have contributed, over what happens to their contributions. In any case (as has become apparent to me following the discussion on the ALUG wiki), there is a need for regular and frequent back-up of the contents, so that things can be rolled back if necessary. Just some thoughts ... I like the idea, but feel wary! Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 28-Oct-05 Time: 21:00:53 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Groff wiki?
On 28-Oct-05 Robert Goulding wrote: > On Oct 28, 2005, at 3:13 PM, Werner LEMBERG wrote: > >>>> With all the discussion recently on the need for groff documents >>>> teaching fundamentals and techniques - and with all the terrific >>>> stuff that is frequently posted to this list (most recently, Ted's >>>> solution for pie-graphs), it seems to me that a wiki for groff >>>> would be very useful. >>> >>> Agreed. >> >> Me too. Any volunteers who has time, the ability, and the interest to >> set up a wiki? And who is willing to maintain it (this is, walking >> through the mailing list archive and putting the various solutions >> into the wiki)? >> > Since I brought up the subject, I should be the first to jump in! > While I don't have the expertise to set up the thing, I will volunteer > to start trawling the archives and posting them to the wiki. Perhaps, > to share effort, anyone who is interested could take a year to work on. > If that sounds a feasible way to do it, then to start the ball > rolling, I'll take on 2004. A good start! Can I join in? If still for sale, can I have 2003 then? A propos issues arising with wikis, I just read back over the recent ALUG discussion which I mentioned. There are some thoughts in there that we may find helpful. If you want to look at them, go to http://lists.alug.org.uk/main/2005-October/thread.html scroll down (it's fairly near the top) to thread: [ALUG] WiKi Status Enquiry Keith Watson and follow it down. I confess I am no sort of expert whatever on the technicalities behind wikis, so eom of that material was over my head. Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 28-Oct-05 Time: 21:31:33 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Drawing filled circle segments
On 28-Oct-05 Tadziu Hoffmann wrote: > > Lots of fun with pie charts. Just for the heck of it, here's a > modified version of Ted's pie-chart mechanism that "remembers" > the angles of the wedges and allows you to give the wedge size > as a percentage of the whole "pie" (plus, it allows you to use > "groff" colors; the \N'32' (which should be a space) fools groff > into thinking it's printing something and makes it output the > code to change color, which it otherwise wouldn't do). [code snipped] Also very nice! (in both versions). Ted ---- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 28-Oct-05 Time: 22:12:50 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Groff wiki?
On 28-Oct-05 Bernd Warken wrote: > > There is a wiki page with an article on groff: > http://en.wikipedia.org/wiki/Groff. > > It is quite small. The German version > http://de.wikipedia.org/wiki/Groff > is different and much larger. Strangely enough, it comments > `lbl' as supported preprocessor. Wirklich! I had not heard of this till you mentioned it (above), but a little search has led me to comp.sources.unix at http://www.isc.org/index.pl?/sources/ and, specifically, http://www.isc.org/sources/utils/text/processing/lbl.php where: Title:lbl Version: 1.0 Submitted:Dec 1 1986 Author: wjh12!maynard!campbell Submittor:wjh12!maynard!campbell Description: lbl preprocessor for [nt*]roff The following shar archive contains the lbl preprocessor for [nt*]roff. lbl handles generation of and symbolic references to sequenced labels, alphabetic, numeric, or mixed. Forward references are supported. Lbl was written by C.D.F. Miller at Heriot-Watt University (Scotland), and was originally posted to net.sources over a year ago. It compiled and ran without a hitch on my tiny VENIX system and has performed flawlessly ever since; this is high praise indeed for a net.sources widget. Hence, this shar archive contains the author's original code and documentation, untouched. Share and enjoy. Could be interesting! Best wishes, Ted. -------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 29-Oct-05 Time: 00:17:58 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Groff wiki?
On 28-Oct-05 Larry Kollar wrote: > > Bernd Warken wrote: > >> >> There is a wiki page with an article on groff: >> http://en.wikipedia.org/wiki/Groff. > > There's a troff page, with a very familiar-sounding history, > at http://en.wikipedia.org/wiki/Troff > >> It is quite small. The German version >> http://de.wikipedia.org/wiki/Groff >> is different and much larger. Strangely enough, it comments `lbl' >> as supported preprocessor. > > I'll bet that's a typo & it's supposed to be "tbl" instead. I thought so at first glance -- but the preprocessors listed are tbl, eqn, pic, lbl, refer; so 'tbl' is already there. When you look at what they do: tbl Tabel eqn mathematische Ausdrücke pic Grafiken lbl Untertitel von Tabellen und Bildern refer Bibliografische Verweiselen you see it says that 'lbl' does "Subtitles/captions for tables and figures" -- which is not quite right (see my earlier post) but in the right area. Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 29-Oct-05 Time: 01:00:06 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Drawing filled circle segments
On 30-Oct-05 Amber Hassaan wrote:
> Hi Werner,
>Having read solutions posted to the
> forgoing problem by Ted and others,I think the task is
> solved for now.But I would rather that(in coming
> releases of groff):
> 1.pic had some construct like filled arc and filled
> polygon.(in addition to \D request)
> 2.\D'***' request could be enhanced to draw filled
> arcs with \D'A ***' in addition to the original arc
> request \D'a ***'.
>
> best regards
> amber
This comes back to a general point I made some time earlier
(in the discussion on shaded/coloured boxes with round corners):
that 'pic' lacks (for this particular kind of thing) the facility
to "close" a general object, i.e. you could draw an outline
with joined-up liness and curves, declared it "closed" (which
would correspond to the PostScript command "closepath" in the
background) and then proceed to fill/shade it (just as with
"fill" in PS).
It might seem that 'pic' depends on a somewhat limited class of
primitives, but basically so does PostScript itself at that level,
yet there's no limit to what can be drawn therewith!
Not that I'm suggesting that making 'pic' more usable in the
broad sense is trivial!
There's another development one can make from a point made by Werner
below, for which see at end.
> --- Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>
>> > It works well for what I need right now, but the macro approach
>> > makes sense provided groff supports sine, cosine, and tangent
>> > functions...
>>
>> Given that groff doesn't have a `float' data type only ad-hoc
>> solutions for the trigonometric functions, suitable to a specific
>> problem, make sense IMHO.
>>
>>
>> Werner
While that is true for groff, it's not true for 'pic', and it can
often be useful to use 'pic' in-line for purely compytational work.
For this, however, you have to add an extra option to the ".PS"
and ".PE" macros in whatever package you use, so that their
occurrence will have no visible effect on the page.
For instance, I temporarily ".PS" in the "ms" macro package to
accept the option "T" (for "Tacit" in general, or "Table" which
was what I first used it for):
.de PS
.ie '\\$3'T' \{\
.ds pic*Table T
.\}
.el \{\
.ds pic*Table
.br
[all the rest of the normal .PS]
.\}
and
.de PE
.ie '\\*[pic*Table]'T' .rm pic*Table
.el \{\
[all the rest of the normal .PE]
.\}
With those planted, you can now do floating-point arithmetic in 'pic',
and make the results available to troff.
Here is an example (including the full ".PS" and ".PE" macros from
"ms" as revised above). Granted, the particular shapes drawn here
in the main graphic can as well be done using "raw pic", but I'm
giving it to illustrate the use of 'pic for "in-line" numerical
computation in groff source: note that 'pic' has not been used to
actually *draw* anything! It's role is purely numerical (and also
to pass the computed commands to groff).
Run
groff -pe -ms
on it (you need the "e" as well, at a couple of points).
.de PS
.ie '\\$3'T' \{\
.ds pic*Table T
.\}
.el \{\
.ds pic*Table
.br
.sp \\n[DD]u
.ie \\n[.$]<2 [EMAIL PROTECTED] bad arguments to PS (not preprocessed with pic?)
.el \{\
. [EMAIL PROTECTED] (u;\\$1)+1v
. in +(u;\\n[.l]-\\n[.i]-\\$2/2>?0)
.\}
.\}
.HTML-IMAGE
..
.de PE
.ie '\\*[pic*Table]'T' .rm pic*Table
.el \{\
.HTML-IMAGE-END
[EMAIL PROTECTED]
.sp \\n[DD]u+.5m
.\}
..
.LP
.PS
pi = 4*atan2(1,1)
command ".ds s60 " sprintf("%0.3f",sin(pi/3))
command ".ds c60 " sprintf("%0.3f",cos(pi/3))
.PE
.LP
cos 60\(de $=$ \*[c60] and sin 60\(de $=$ \*[s60],
so here is a nice little polygon:\0\
\v'-0.5n'\
\Z'\D'p \
\*[c60]n -\*[s60]n 1n 0\*[c60]n \*[s60]n \
-\*[c60]n \*[s60]n -1n 0 -\*[c60]n -\*[s60]n'\
\v'0.5n''
.LP
But you can also use \f[CR] .PS T \fP to loop through numbers:
.br
.sp 2i
.ds poly \Z'\D'f \\*[gray]''\Z'\h'3i-\\*[x0]'\D'P \
\\*[dx] -\\*[dy] \\*[dh] 0 \\*[dx] \\*[dy] \
-\\*[dx] \\*[dy] -\\*[dh] 0 -\\*[dx] -\\*[dy]''
.PS T
for j = 1 to 10 do { i = 11-j
command ".ds gray " sprintf("%.0f", 1316 - sqrt(10*i))
command ".ds x0 " sprintf("%0.3fi",(0.5+cos(pi/3))*sqrt(4*i/10))
command ".ds dx " sprintf("%0.3fi",sqrt(4*i/10)*cos(pi/3))
command ".ds dh " sprintf("%0.3fi",sqrt(4*i/10))
command ".ds dy " sprintf("%0.3fi",sqrt(4*i/10)*sin(pi/3))
command "\*[poly]\c"
}
.PE
For a different effect, change the "for" line in the 'pic'
loop to
for j = 1 to 100 do { i = (101-j)/10
Best wishes to all,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 30-Oct-05 Time: 22:09:06
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
[Groff] Test -- apologies
Please excuse this test which I need to carry out. Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 01-Nov-05 Time: 11:31:40 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] maintain status b/w pic figures
On 03-Nov-05 Amber Hassaan wrote:
> Hi everyone,
> Please tell me, if I can use variables or
> positions from one pic diagram in another pic
> diagram.I think I might be able to use self-defined
> registers or strings perhaps but I can't figure out
> how.
>
> best regards
> amber
Hi Amber,
Anything defined or given a value in one .PS ... .PE block
is available to all subsequent blocks, unless subsequently
changed.
So you can give a particular variable a value once, and it
will have that same value in all later blocks (unless you
change its value along the line).
Similarly, pic macros defined in one block remain available
in later blocks (unless undefined by "undef"), and so do
named "objects" defined like
A: []
and so on (actually pic calls [] a "block", which is
obviously not what I meant by "block above!).
For example:
.PS
k = 10
define circles {
circrad=$1 ; n=$2 ;
for i = 1 to n do {
circle rad circrad*(1 - i/n) at (0 + i*circrad/n,0) fill i/n
}
sprintf(" %.0f Circles",k) at last circle .e ljust
}
.PE
and then, after some text,
.PS
circles(0.5,20)
.PE
which is clearly incorrect, so correct it with
.PS
k = 20
circles(0.5,20)
.PE
Best wishes,
Ted.
--------
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 03-Nov-05 Time: 18:00:55
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
[Groff] "creep" and booklets
Hi Folks,
I'd welcome views and contributions about the following.
It concerns making a "booklet" out of a PS document.
1. Background:
If you have (say) a 16-page PS document, you can run it
through the following pipelikne:
cat doc.ps | psbook | psnup -2 > doclet.ps
and doclet.ps will have a series of 8 pages, each with 2
of the original pages as follows:
1: 1 & 16
2: 2 & 15
3: 3 & 14
4: 4 & 13
5: 5 & 12
6: 6 & 11
7: 7 & 10
8: 8 & 9
You can now print out pages 1, 3, 5, 7 on one side of 4 sheets,
turn these over, and then 2, 4, 6, 8 on the other side. You then
get 4 sheets with printing as follows:
1 16
+
2 15
3 14
+
4 13
5 12
+
6 11
7 10
+
8 9
You can then staple these at "+", fold carefully down the middle,
and you have a nice little booklet which you can read in the
usual way.
Now here's the point. Because of the thickness of the paper,
the middle pages (toward the bottom of the above pile) are
puched outwards. To tidy this up, you can take a guillotine
and slice of the protruding bits (of all except the first).
However, this then leaves the print closer to the outside
edges on the centre pages that it is on the outside pages,
prgressively creeping outwards. This is what's called "creep"
and it can become quite noticeable.
So you then need to correct this, which can be done (and quite
easily in groff) by making small adjustments to the page offset
as you go from page to page (the details depend on what macro
package you use, but essentially require something to be done
in the macro which initiates a new page).
This requires offset changes, relative to normal printing,
as follows:
0 1 16 0
+
0 2 15 0
-1 3 14 +1
+
+1 4 13 -1
-2 5 12 +2
+
+2 6 11 -2
-3 7 10 +3
+
+3 8 9 -3
where (e.g.) "-2" means that the print on that (original) page
is to be shifted 2 creep-units to the left, and "+2" means 2
units to the right, relative to normal printing.
A fairly straightforward algorithm: odd pages left, even pages
right, by amounts increasing up to halfway, and then decreasing.
Note that 'psbook' will add extra blank pages so as to bring
the total up to a multiple of 4 (e.g. if the original had only
13 pages).
There are two things you need to know to determine exactly
how to do this. One is the total number of pages you will be
getting (which can be found from a dummy pass), so that you
can tell the algorithm where halfway is.
The other, of course, is the size of the "creep unit", and
this can only be found empirically. Print, staple, and slice;
then measure the change in width from outside to middle,
and divide by the number of sheets.
2. Groff implementation.
As I said, it's not difficult to arrange this in groff, by
suitably modifying your top-of-page macro.
a) First question. I think it's probably difficult, if not
impossible, to write a "universal macro" which would work
with any of the usual macro sets ("ms", "me", etc).
Comments?
b) This wheel has undoubtedly been invented already.
Anyone out there got good implementations?
c) I'm refining a macro for "ms" at the moment. Interested?
3. Practicalities.
These concern how you actually manipulate the paper, etc.
It's my experience that unless you're very careful, it's
difficult to get good and consistent results. Where things
can go slightly wrong are in putting the staples exactly in
he middle, in folding, and in slicing off the protruding
bits.
Adequate results are quite easy though.
Any suggestions about procedure, from people who've been
along this road before? This could include recommendations
about the use of equipment to properly hold the pages when
being stapled and folded, to ensure a good clean fold, etc.
Preferably suitable for implementation on the kitchen table.
Then there are ths issues that arise with larger documents,
where you eed to make them up of "signatures" each with few
sheets. With standard 80gm/m2 printer paper, I've found that
16-sheet signatures are about as far as one wants to go.
I've found that good-quality thinner paper is hard to come by.
Having got your signatures, they then need to be attached
together. For this, it's not ideal if each signature was
stapled. Any recommendations for (a) making the central
attachment for a signature instead of stapling; (b) binding
signatures together?
With thanks, and best wishes to all,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 04-Nov-05 Time: 00:01:08
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] "creep" and booklets
On 04-Nov-05 Bob Diertens wrote:
> On Fri, Nov 04, 2005 at 12:01:12AM -0000, Ted Harding wrote:
>> Hi Folks,
>>
>> I'd welcome views and contributions about the following.
>>
>> It concerns making a "booklet" out of a PS document.
>>
>> 1. Background:
>> If you have (say) a 16-page PS document, you can run it
>> through the following pipelikne:
>>
>> cat doc.ps | psbook | psnup -2 > doclet.ps
>>
>> [ ... ]
>
> You can easily do this by manipulating the PostScript file.
> The Perl script below suffices.
>
> usage:
>cat doc.ps | psbook | creep 0.5 | psnup -2 > doclet.ps
>
> Hope this helps,
> Bob
Excellent idea! And thanks for the snappy response. This would
take the problem out of groff which would be a good thing for
this application (especially since the amount of creep required
=depends on the thickness of paper you are printing to, and I'm
much happier not to have to plant that in the groff source).
I take it, from the look of things, that $creep_incr is in points?
I don't tangle with perl as a rule, but this provides a motive!
(Though it looks as though it would translate well to awk, so
that may keep me happy for a bit).
I'll need to test this a bit on groff output (and other PS
documents). One thing I'm wondering about is whether it would
be wise, for general use, to encapsulate the page in
gsave 0 translate [rest of page] grestore
For instance, I just tried it on a PS file (not from groff)
and it did not work. The reason seems to be that each page
begins like:
%%Page: 1 1
0 0 translate
%%BeginPageSetup
etc., which would undo your creep! I think the trigger for inserting
the "grestore" would normally be the occurrence of "showpage", but
this may get wrapped into a definition (as it does in groff, where
"EP" is used, defined as
/EP{
level0 restore
showpage
}bind def
However, on trials so far the script does seem to work as it stands
on PS files produced by groff. Groff's PS output also defines a "BP"
to initiate the page, which does not include a "translate" command
of its own, so there should not be a need for "gsave ... grestore".
Thanks!
Ted.
> ---begin creep---
>#!/usr/bin/perl
>#
># Enjoy: Bob Diertens, 11/04/2005
>
> if ($#ARGV != 0) {
> die "usage: $0 \n";
> }
> $creep_incr = shift;
>
> $pagecount = 0;
> $creep = 0;
>
> while (<>) {
> print;
> if (/^%%Page:/) {
> if ($pagecount % 2) {
> print "-$creep 0 translate\n";
> } else {
> print "$creep 0 translate\n";
> }
> $pagecount ++;
> if ($pagecount %4 == 0) {
> $creep += $creep_incr;
> }
> }
> }
> ---end creep---
>
>
> ___
> Groff mailing list
> Groff@gnu.org
> http://lists.gnu.org/mailman/listinfo/groff
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 04-Nov-05 Time: 12:21:13
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Typesetting arbitrary fractions?
On 05-Nov-05 Robert Goulding wrote: > On Nov 4, 2005, at 10:46 PM, T. Kurt Bond wrote: > >> What's a good way to typeset arbitrary fractions like 1/100 and 1/1000 >> after the styel of \(12? >> > Preprocess with eqn (i.e., groff -e -ms): > > .EQ > delim $$ > .EN > .LP > We can write one-thousandth as $1 smallover 1000$. That's a bit off the original question! \(12, like \(14 and \(34, is a glyph in its own right (indeed with its own iso-8859-1 code, so you should be able to see ¼ ½ ¾) and I presume this is the style which Kurt wants to emulate. So you see a small raised "1", a sloping bar which goes well under it (almost to the left of the "1", and then a small "2" on the baseline, well tucked under the sloping bar. The ordinary AScII "/" does not have the slope to make this look right, and it's better to use the similar character in the Symbol character set (PostScropt name "fraction") whose groff name is "\(f/" In fact, when I set \(12 and \(f/ side by side in TR and view at hign magnification, the two sloping bars seem to be identical (which is what you would expect in a properly designed font family). However, this would not necessarily transfer to other fonts, since the \(f/ in standard PostScript occurs only in the Symbol font and so there is only one version of it. None the less, I have made the comparison in some standard Adobe font families (Times, Bookman, Palatino, Helvetica) and the bar in \(12 in all seems to be identical to \(f/ in Symbol. So, with that settled, we can address Kurt's question. The following is only a version which I judge by eye to be about right, in that it seems to give the same results for the composed fraction when applied to "1/2" for which there is a single glyph. .de frac .nr n0 \\n[.s] .nr n1 \\n[n0]*6/10 .nr dn (\\n[n0]-\\n[n1])*8/10 \v'-\\n[dn]p'\s[\\n[n1]]\\$1\s0\v'\\n[dn]p'\[f/]\s[\\n[n1]]\\$2\s0 .. Test it: \f[HR]\s[40]\(12 .frac 1 2 .frac 999 1000 .sp \f[TR]\s[30]\(12 .frac 1 2 .frac 999 1000 .sp \s[30]\(12\f[TB] .frac 1 2 .frac 999 1000 Note that it seems fine in HR (first test), but in TR the "1" and "2" in ".frac 1 2" are in TR while in "\(12" these figures seem to be heavier (though not quite bold), as confirmed in the third test. So that's the basics of doing it, but clearly you have to watch out for detail depending on the environment. Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 05-Nov-05 Time: 09:04:27 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] gs, gv
On 06-Nov-05 mikkel meinike wrote: > Hallow agan > > I have now installed gs and the viewer gv on my BL3 system but when I > try to see a ps file I can't do that I get an error messages > gv alphabet.ps > > The xterm window display > Warning: ... fund while parding 'apLineDel: > GV_Page(page+5) > Warning: Unable to load any usable fontset I am not an expert on gs or gv, so probably can not help in detail. However, one thing I do know is that gs and its fonts are often two separate packages, and both need to be installed. This message suggests that the ghostscript fonts were not installed. Check the installation documentation for Slackware in PACKAGES.TXT, and note in particular that: "If you need X11 support, you should also install the package 'gs_x11' found on the XAP series. It contains a /usr/bin/gs with support for X11." This may resolve the problem you report below. > The gv windows Oppens and this massages pups up > Ghost Script Massages > unknown device: x11 > Dismiss > > So it looks like the problem is in the settings of gs. I found out > that my ghost script that is from slackware4 as default sent the > output to CLI svgalib. > gs alphabet.ps > from an X11 xterm does: Black screen some fast massages about svgalib > and something about buss error and than fall back to X11 with > > svgalib: allocated virtual console #5 If installing gs_x11 (see above) does not solve it, then this looks like a problem with the graphics library, svgalib in your case, or in the interface with your hardware, or possibly a hardware problem (incorrect settings of display parameters when setting up X11?). Have you tried displaying files in other graphics formats (e.g. JPEG [".jpg"] files, GIF [".gif"], etc.) in X? Does X itself start well? > How can I change the settings so it will use X11 and I assume the X11 > fonts, and so that gv can display my ps files? and also I have a very > low screen 480x600 should I set a special resolution for this screen > or will that work out automatically with the vga16 server > /Mikkel > > /Mikkel My best suggestion is that you should subscribe to a good Linux list (if you are not already on one), and discuss your problem in detail there. Good luck! Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 06-Nov-05 Time: 17:36:53 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Macro arguments question
On 13-Nov-05 Clarke Echols wrote:
> One thing I *really* like about groff vs troff/ditroff is the
> expansion of macro and other entity names beyond two characters.
> Nice job!
>
> I am considering using macros to solve a problem that would be better
> if handled in a database, but I don't want to write the software to
> do it. However, it would be nice if I could string some multi-line
> text together as a single argument to a macro. However, it is not
> obvious to me that it can or cannot be done the way I'm thinking. I
> have been considering something on this order:
>
> .macro \{
> "text line 1, blah blah blah
> text line 2, blah blah blah
> text line 3, more here"\}
>
> I would like to have the text processed as a single argument to
> the macro just as groff would handle:
>
> .macro "argument number one"
>
> and then wrapped and adjusted as with normal text from a
> typical input file.
Hi Clarke,
Maybe I'm missing something, but would the following be something
you do not want to do, for some reason?
.macro \
"text line 1, blah blah blah \
text line 2, blah blah blah \
text line 3, more here"
> 1. Will this work?
Your example above perhaps does not work as (seems to be) intended,
i.e. if I define
.de temp
\\$1
..
.temp \{
"text line 1, blah blah blah
text line 2, blah blah blah
text line 3, more here"\}
then I get
"text line 1, blah blah blah text line 2, ... line 3, more here"
as one line (presumably as intended), but with the quotes as well,
which I suspect you don't want. But this is a consequence of
wrapping it in \{...\}, so if you just remove the quotes from
your argument it comes out right.
>
> 2. If not, is there a different, quick-and-easy/dirty way
> to do it?
>
> Any opinions out there?>
Maybe see above ... ?
Best wishes,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 13-Nov-05 Time: 22:34:02
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] picture placing
On 14-Nov-05 walter harms wrote: > Hi list, > is there an easy way to place a picture ? > > The design (a4 long): > two on top of each other with 4 and 3 columns. The "empty" column > should > be filled with a piucture. i tried with .PSPIC and \X:import > but causing havoc the to page onlY > > basicly it should look like this. 2 tables and X marks the picture. > > +--+--+--+ > +--+--+--+ > > +--+--+\/ > +--+--+/\ > > re, > walter There are several oprtions for this sort of thing, depending on precisely what you want to do. I have to make this a quick reply, so here is one way. Suppose you want the picture to really belong to the second table. Define -- before you embark on the table -- a string .ds mypic \Z''v'XXXu'\X'ps: import picture.eps llx lly urx ury Wunits'' where: XXX is the intended height of the picture in units, picture .eps is the EPS file of your picture, llx, lly, urx, ury are the coordinates of the bottom left and top right coirners of the picture (you get these from the "%%BoundingBox: llx lly urx ury" line in the EPS file), Wunits is the number of units of the printed width of the picture that you want (units = 1000xPoints). You may have to edit some of these numbers (XXX in particular, also perhaps Wunits) to get the right result. Then you can set up your table 2 like .TS tab(#); l l l. Row1 Col1#Row1 Col 2#\*[mypic] Row2 Col1#Row2 Col2# ... .TE The "\Z'...'" in \*[mypic] means that drawing the picture will cause no displacement of the printing position from the point where it was initiated, so should not mess up anything. And, in other contexts, you can use the same "\Z'...'" device for the same purpose. Hoping this helps, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 14-Nov-05 Time: 10:59:42 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] u1D53C glyph
On 16-Nov-05 Fabrice Ménard wrote:
> Hi, all !
>
> I need the glyph E open face (u1D53C) for a math doc.
> Does anyone know a good font containing this one and how to set it up
> with grops ?
>
> Regards.
>
> --
> Fabrice Ménard
> [EMAIL PROTECTED]
Once, for similar reasons, I set up a whole open=face font (using
Helvetica-BoldOblique as a base), on the same principles as used in
groff for the SS and ZDR fonts: the .pfa file for the font
simply contains PS code the give the outlines of the glyphs,
not filled.
Working in the .../font/devps directory, the relevant PS code
(in my file "openI.pfa) is
%!PS-Adobe-3.0 Resource-Font
%%DocumentNeededResources: font Helvetica-Bold-Italic
%%DocumentNeededResources: font Helvetica-BoldOblique
/makeoutlinedict 7 dict def
/MakeOutlineFont
{ makeoutlinedict begin
/uniqueid exch def
/strokewidth exch def
/newfontname exch def
/basefontname exch def
/basefontdict basefontname findfont def
/numentries basefontdict maxlength 1 add def
basefontdict /UniqueID known not
{ /numentries numentries 1 add def } if
/outfontdict numentries dict def
basefontdict
{ exch dup /FID ne
{ exch outfontdict 3 1 roll put }
{ pop pop }
ifelse
} forall
outfontdict /FontName newfontname put
outfontdict /PaintType 2 put
outfontdict /StrokeWidth strokewidth put
outfontdict /UniqueID uniqueid put
newfontname outfontdict definefont pop
end
} def
%%IncludeResource: font Helvetica-BoldOblique
/Helvetica-BoldOblique /openI 1000 54 div
/Helvetica-BoldOblique findfont dup /UniqueID known
{ /UniqueID get 1 add }
{ pop 1 }
ifelse
MakeOutlineFont
The whole thing happens in the "outfontdict /PaintType 2 put"
line.
I then simply copied the "HBI" font to file "openI",
so as to get the font metrics etc, changing the first two
lines to
name openI
internalname openI
Then (just as for SS and ZDR) I added an entry to the
"download" file. After that, the font is available and
can be used by giving \f[openI] and so forth.
So you can do similar, with whatever font you choose
as base, giving the result whatever name you like.
Hoping this helps,
Ted.
--------
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 16-Nov-05 Time: 12:56:35
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] u1D53C glyph
On 16-Nov-05 Fabrice Ménard wrote: >> So you can do similar, with whatever font you choose >> as base, giving the result whatever name you like. > > It looks particulary great with Times-Roman > >> Hoping this helps, >> Ted. > > Thanks a lot for the trick! I'm pleased that it worked! By the way, I forgot to mention that of course the new font should be mentioned in the DESC file, along with any others that might get used, but it seems you must have done that. The "trick", by the way, is simply an appropriate modification of code copied from Program 16 in the "PostScript Language Tutorial and Cookbook" (so-called "blue book") from Adobe. Well worth having by you, for little things like this. Best wishes, Ted. -------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 16-Nov-05 Time: 13:59:37 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] string variable in pic
On 11-Dec-05 Heinz-Jürgen Oertel wrote:
>
> Hello,
> I'm searching for a way to put strings in pic variable,
> but found no way doing it.
> What I like to do is something like:
>
> .PS
> bcolor = "red"
>
> define cbox {
> box wid $1 color bcolor
> }
> .PE
>
> .PS
> cbox(1) "this is red"
> bcolor "yellow"
> cbox(1) "this is yellow"
> .PE
I *think* (but am not absolutely sure) that the reason your
approach does not work is that the assignment "=" has the syntax
variable = expression
and, as far as I can tell, "expression" in pic can only be numeric
(or logical), so that there is no such thing as a string-valued
expression (or variable). More generally, a string (either quoted
literally or as returned by 'sprintf') is an object, like 'box'.
However, it is possible to do what you want by macro substitution:
.PS
define cbox {
box wid $1 color $2
}
.PE
.PS
bcolor="red"
cbox(1,"red") "this is red"
cbox(1,"yellow") "this is yellow"
.PE
This does not evaluate any expressions: When (e.g.) "red" is
encountered in 'cbox(1,"red")' it is substituted for $2 in
the definition of 'cbox', i.e. it effectively re-writes 'cbox'.
Hoping this helps!
Ted.
>
> Another interesting feature would be if
> \n[.M] could return the numerical values of the color components.
> In this case one could define a new color which is sometimes darker or
> more
> bright, or "more red" etc. This can be used to produce shaded colored
> boxes
> in pic.
>
> Hope I get help
> Regards
> Heinz
>
>
>
> ___
> Groff mailing list
> Groff@gnu.org
> http://lists.gnu.org/mailman/listinfo/groff
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 11-Dec-05 Time: 14:02:36
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] string variable in pic
On 11-Dec-05 Heinz-Jürgen Oertel wrote:
> Thanks Ted,
> The reason for placing some values in a "global" variable is
> avoiding a large number of macro arguments having always the same
> value. Like with the variable "slant" in my example.
> Look at the example I'm just trying:
>
>
> .fam H
> .PS
>
> slant = .2
>
>
> define arrowbox { [
>
> box xslanted -slant color $1 $3
> box xslanted slant color $2 $3 \
> with .ne at last box.se + ( -slant, 0)
> # place a box centered above both slanted boxes
> box ht 2*boxht invisible \
> with .ne at 1st box.ne + ( -(slant/2),0)
> ] }
> .PE
>
> .PS
> arrowbox("darkgreen", "darkgreen") \
> "\m[white]1st" "first" "colored" "box"
> arrowbox("darkgreen", "darkgreen") \
> "2nd" "second" "colored" "box"
> arrowbox("darkgreen", "darkgreen") \
> "3rd" "third" "colored" "box"
> arrowbox("darkgreen", "darkgreen") \
> "4th" "fourth" "colored" "box"
> .PE
>
> .PS
> slant = .3
> arrowbox("tomato", "tomato") \
> "\m[black]1st" "first" "colored" "box"
> move -0.2
> arrowbox("tomato", "tomato") \
> "2nd" "second" "colored" "box"
> move -0.2
> arrowbox("tomato", "tomato", outline "white") \
> "3rd" "third" "colored" "box"
> move -0.2
> arrowbox("tomato", "red") \
> "4th" "fourth" "colored" "box"
> .PE
> -
> The result is attached.
> Is the only way extending pic to accept strings in expressions, or at
> least
> in variable assignments?
>
> Regards
>Heinz
I have found out a way to do it -- essentially, you use the macro
mechanism, but the trick is to define the macro so that the
quotation marks are included in the replacement text.
To take your simple box example as illustration:
.PS
define bcolor { "red" }
define cbox {
box wid $1 color bcolor
}
.PE
.PS
cbox(1) "this is red"
define bcolor { "yellow" }
cbox(1) "this is yellow"
.PE
This ensures that occurrences of
bcolor
are replaced by
"red"
or
"yellow"
*including* the quotation marks!
Best wishes,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 11-Dec-05 Time: 21:29:45
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Floating point arithmetic in groff
On 31-Jan-06 M Bianchi wrote:
> On Tue, Jan 31, 2006 at 07:38:54AM +0100, Werner LEMBERG wrote:
>> > Is anyone aware of a means by which floating point arithmetic
>> > and formating can be computed either within groff or in a
>> > preprocessor (ala eqn, tbl, etc.)?
>>
>> Not that I know of. Why do you need it?
>
> I use groff -mm for all my documents, and sometimes have tables
> that are
> Quantity Each Total
>
> and it would be nice to simply be able to use floating number
> registers to do the arithmetic.
Unfortunately groff's numner registers are integer-valued!
Also, groff's table-formatting resources do not include a
built-in facility to make calculations (spreadsheet-style)
using the table entries (unlike some word processors).
There are a few approaches to what you want to do.
One would be to run your source file through 'awk' before
groff sees it, and let 'awk' fill in the calculated values.
Within groff, you can use 'pic' which has a good numerical
engine built in to it. Again, there are diferent ways of doing
this, but a straightforward one is as follows.
Suppose you have a file "temp.pic", say, which contains
two columns, one for "Quantity" and the second for "Each",
like
7 13.5
21 35.5
9 11.99
27 46.25
Then you can write a troff source file "temp.tr" as follows:
.P
.PS
total=0
gtotal=0
define mktotals {
total = $1*$2
gtotal = gtotal + total
command sprintf("%.0f#%.2f#%.2f",$1,$2,total)
}
.PE
Here is your itemised bill.
.PS
command ".TS"
command "center tab(#);"
command "c c c."
command "Quantity#Each#Total"
command "_"
command ".T&"
command "n n n."
copy "temp.pic" thru mktotals
command "="
command sprintf("##%.2f",gtotal)
command ".TE"
.PE
Finally, run this through 'pic' and then troff as follows
(see below for comment on the 'awk' section of the pipeline):
pic temp.tr | awk '/^\.lf/{next}; {print $0}' | groff -t -mm > temp.ps
which will produce a PS file which contains what you would want
in this case. Using the "ascii" device with the command
pic temp.tr | awk '/^\.lf/{next}; {print $0}' | groff -Tascii -t -mm
produces the output:
- 1 -
Here is your itemised bill.
Quantity Each Total
---
7 13.50 94.50
21 35.50745.50
9 11.99107.91
27 46.25 1248.75
---
2196.66
The reason that "| awk '/^\.lf/{next}; {print $0}" is there
in the pipeline is that the ".lf" lines output by 'pic'
seem to confuse 'tbl'; the 'awk' step removes them.
Hoping this helps,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 31-Jan-06 Time: 15:05:41
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Re: begin page blues
On 18-Feb-06 Miklos Somogyi wrote: > [...] > Here's an artificial example just to see the extra space at work: > > .vs 0.85c > .ps 20 > .ft CR > .sp 10 > Hello1 > \X'ps: exec 1 0 0 setrgbcolor' > Hello2 > Hello3 > \X'ps: exec 0 0 0 setrgbcolor' > .br > Hello1 Hello2 Hello3 > .\" > .ex > > Here the red Hello2 Hello3 are one space to the right of the black > ones. > Does anyone know the how and why of this space? Yes -- it comes from the LF in the input that follows \X'ps: exec 1 0 0 setrgbcolor' You would get the same (without the colour change) from Hello1 \& Hello2 Hello3 \X'ps: exec 0 0 0 setrgbcolor' .br Hello1 Hello2 Hello3 (i.e. the zero-width non-printing character "\&"). To get what you want, you can do it as Hello1 \X'ps: exec 1 0 0 setrgbcolor'\ Hello2 Hello3 \X'ps: exec 0 0 0 setrgbcolor' .br Hello1 Hello2 Hello3 so as to "hide" the LF, or as Hello1 \X'ps: exec 1 0 0 setrgbcolor'Hello2 Hello3 \X'ps: exec 0 0 0 setrgbcolor' .br Hello1 Hello2 Hello3 Hoping this helps with your real example! Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 18-Feb-06 Time: 21:52:48 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: begin page blues
On 21-Feb-06 Miklos Somogyi wrote: > [...] > I only have one philosophical question-mark. When I was a > youngster (yes!), device independence and pre- and > post-processors were good ideas and necessary. > I wonder whether it still is the case. > We, who got used to them, are comfortable with them. > I'm not so sure about today's youngsters. > Probably they would say that the dust has settled, Adobe won > (whether they like this or not), so why concentrate on > anything else than ps and pdf. > And perhaps they would like a single application better, > a groff with built-in tbl, eqn, me or mm etc, producing, > say, only ps. I don't know, but sometimes it pays if one > questions his/her whole approach As Time Goes By. Interesting questions, and I have thought about them myself from time to time. On balance, I think the existing structure (pre- tbl, eqn, pic etc.; post-devps etc.) works well in most cases and gives flexibility. There are certainly cases where one needs to call one or more of the pre-processors in the "troff" phase of the pipeline, and even interpose a "pre-post-processor between the ditroff output of troff and the final post-processor. Regarding in-line tbl, eqn, pic: This is needed when the operation of the pre-processor depends on something which can only be evaluated during the troff phase. Examples include: a) Computing the width of a box containing text in a 'pic' block. This can only be done using both the text itself and information about the font, the point-size, and the font metrics (e.g. with the "\w'text'" sequence), and the font and its metrics are unknown until troff looks at it; and the text itself may be dynamically generated during the troff phase. b) Computing the values of numerical coefficients in an equation expressed in 'eqn' language, where these may depend on what is in some data file accessed by troff using ".so datafile"; also, the general numerical engine in groff is in 'pic' so as well as in-line 'eqn' you may need in-line 'pic' as well. c) Similarly for 'tbl. It is certainly possible to achieve (a), (b) and (c) by using troff requests to write out lines to a temporary file or files, use the ".sy" request to run 'tbl' or 'pic' or 'eqn' on these saving the results to other temporary files, and then using ".so" to read these results back in. It can get quite complicated to set this up in some cases, and it may be worth while encapsulating the procedure in macros. This may look simple on the surface -- e.g. (in outline) .de pic [open diversion] .. .de /pic [open temp file1] [emit ".PS" to file1] [write diversion to file1] [emit ".PE" to file1] [run pic on file1 writing to file2] .so file2 .. and then, in-line: .pic [pic code using variables already defined] ./pic -- but in practice one can find that it is not straightforward; and it can be even less straightforward if you need to include a call to ".pic" within a call to ".eqn", say. However, I still think that such an approach is probably better than embedding the functionality of the pre-processors within the troff binary. Nevertheless, I have to admit that this attitude may well be a consequence of "youthful" experiences a long time ago, when (as indeed now) this was the only way to do that sort of thing, and once you have taken the trouble to work out how to do it you develop a commitment. Best wishes to all, Ted. [Leaning on his wooden ploughshare] E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 22-Feb-06 Time: 10:10:32 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] List delays
It seems, looking at the headers of recent mails to the list, that postings to the groff list are being delayed at lists.gnu.org by 6-12 hours, typically over 9 hours. Is this (as I hope) a temporary phenomenon? Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 22-Feb-06 Time: 11:00:58 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] RE: List delays
On 22-Feb-06 Ted Harding wrote: > On 22-Feb-06 Ted Harding wrote: >> It seems, looking at the headers of recent mails to >> the list, that postings to the groff list are being >> delayed at lists.gnu.org by 6-12 hours, typically >> over 9 hours. >> >> Is this (as I hope) a temporary phenomenon? >> >> Best wishes to all, >> Ted. > > With Miklos's and Werner's messages of > > Feb 22 07:24 GMT distributed to me 18:24 GMT > Feb 22 07:28 GMT distributed to me 18:41 GMT > > the delays at lists.gnu.org are now at least 11 hours. > > Looking at the list archives at > > http://lists.gnu.org/archive/html/bug-groff/2006-02/index.html > > I see that the archived messages for the last 7 days are 95.5% > spam (some of which is of the well-known groff speciality). > Specifically: > [snip] Sorry! I was looking at the wrong archive! The right place is of course http://lists.gnu.org/pipermail/groff/ which is spam-free (almost). Nevertheless, I continue to wonder if the incidence of spam is causing problems at lists.gnu.org; and I continue (at 21:15 GMT) to wait to see a message I sent to the list at 10:10 GMT this morning (which is however in the archives above), as well. Apologies for the confusion, and best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 22-Feb-06 Time: 21:19:22 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Help: male and female symbols?
On 23-Feb-06 Robert Marks wrote: > Does any of the fonts in the standard distributions of groff contain > characters depicting the standard male and female symbols? > (The circle with the oblique arrow above, and the circle with the cross > below.) > Inquiring minds would like to know. No -- not in the Latin1 encoding for PostScript nor in the Symbol font, nor in Zapf Dingbats (which is not to say that they are absent from utf8 but that's a different question). However, they are simple enough that you can draw your own, defining a ".char" object (which will automatically scale with changes in font size). Define two new characters \[MS] for Male Symbol \[FS] for Female symbol: .char \[MS] \ \Z'\Z'\[ci]'\ \h'\w'\[ci]'u/13u*10u'\v'-\w'\[ci]'u/13u*10u'\ \D'l \w'\[ci]'u/3u -\w'\[ci]'u/3u'\ \Z'\D'l -\w'\[ci]'u/5u 0''\ \Z'\D'l 0 \w'\[ci]'u/5u'''\ \h'\w'\[ci]'u/5u*6u' .char \[FS] \ \Z'\Z'\[ci]'\ \h'\w'\[ci]'u/2u'\ \Z'\D'l 0 \w'\[ci]'u/2u'\ \v'-\w'\[ci]'u/6u'\h'-\w'\[ci]'u/4u'\ \D'l \w'\[ci]'u/2u 0'''\h'\w'\[ci]'u' .LP \s[20]Male Symbol: MM\[MS]MM\s0 .sp .LP \s[20]Female Symbol: MM\[FS]MM\s0 (Using ms macrosm and enclosing the symbols betweem "MM" and "MM" to show how they fit into running text). They look reasonable to me, but you can tweak the metrics and motions to suit your own taste. Hoping this helps, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 24-Feb-06 Time: 22:05:48 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] RE: List delays
On 22-Feb-06 Ted Harding wrote:
> It seems, looking at the headers of recent mails to
> the list, that postings to the groff list are being
> delayed at lists.gnu.org by 6-12 hours, typically
> over 9 hours.
>
> Is this (as I hope) a temporary phenomenon?
>
> Best wishes to all,
> Ted.
With Miklos's and Werner's messages of
Feb 22 07:24 GMT distributed to me 18:24 GMT
Feb 22 07:28 GMT distributed to me 18:41 GMT
the delays at lists.gnu.org are now at least 11 hours.
Looking at the list archives at
http://lists.gnu.org/archive/html/bug-groff/2006-02/index.html
I see that the archived messages for the last 7 days are 95.5%
spam (some of which is of the well-known groff speciality).
Specifically:
Spam Real All
Wed 22 Feb 2 0 2
Tue 21 Feb25 025
Mon 20 Feb24 024
Sun 19 Feb16 420
Sat 18 Feb12 214
Fri 17 Feb30 030
Thu 16 Feb18 018
127 6 133
Does this have anything to so with the delays? Is lists.gnu.org
choking on this stuff?
I am concerned about this, but admit that a solution is not
entirely trivial.
I run a couple of mailing-lists (man-lug and linux-users
@lists.manchester.ac.uk), which are of course targeted
by spammers but at a somewhat lower level (on average
less than 5 spams/day each, but up to 12 or so at times).
The lists are configured to accept postings from subscribers
only. All other postings are notified to me for approval or
other action ("discard" in the case of spam).
This involves a certain amount of work (though not much):
notifications which refer to spam are easily identified and
I leave these alone till I feel like dealing with them.
Maybe once or twice a week a genuine message comes through
from a non-subscribed address (sometimes from an outsider
with an interesting and relevant communication, sometimes
from a subscribed user posting from a non-subscribed address).
When that happens, I then visit the list admin webpage, approve
the genuine message[s], and take the opportunity to flush away
the spam.
Also, both lists have their archives accessible to subscribers
only (password required). This may help to reduce the spam somewhat,
but I am not sure about that (though it certainly helps protect
list-members' addresses from spambots).
I'm not sure about the desirability of making the groff list
subscribers-only, given that one would like to promote open
acess! But things can reach a level where the issue has to be
faced.
Probably restricting reader access to the archives is very
undesirable. The anti-spam effect is likely to be minimal,
while the impact on open access would be severe.
I note, however, that the groff messages which I actually
receive are (except for those few notorious ones "sent" by
a few of us, myself included) are non-spam. At least, that
is the case where there is "[Groff]" in the subject. But
the spam in the archives is otherwise 100% without "[Groff]".
So maybe there is already a mechanism in place for Werner
(or someone) to check out suspect messages; but in that case
why do they get into the archives?
Or maybe some of the multitude of spam which I receive (but
never look at) is also sent out by lists.gnu.org but without
["Groff]" in the subject. I'm a bit perplexed by my observations.
Just raising some thoughts for consideration! (And hoping
that the gridlock eases enough for discussion to begin to
flow again).
Best wishes to all,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 22-Feb-06 Time: 20:06:28
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] incorrect position of 'caron' glyph??
On 07-Mar-06 Joerg van den Hoff wrote: > hi everybody, > > I noted the following. when defining > > > .ds Macasek "Mac\['a]\o'\[ah]s'ek > .ds macasek "Mac\['a]\[vs]ek > .DS > \*[Macasek] > \*[macasek] > .DE > > > one gets an optically pleasing 'scaron' (\[vs] (second line), but a > seemingly slightly off-center (to the left) 'caron' (\[ah]) if you > overstrike it with the letter 's' (first line). > > at least if one generates pdf output and really zooms in ... > > in short, my question is: > > should > > \o'\[ah]s' > > yield exactly the same as > > \[vs] Not necessarily. It depends: a) If you are using a PS font which includes the s-hacek as a single glyph, and this is accessed, as such, from groff using "\[vs]", then you can expect this to be "perfectly formed" anyway. b) When you use "\o'\[ah]s'" to create the composite character by over striking "\[ah]" with "s", then the alignment may not be perfect. Essentially, "\o'XY'" simply prints "X", then moves back and prints "Y" so that the horizontal centre of "Y" is at the horizontal centre of "X". While one may expect the metrics of "\[ah]" to be well chosen as a compromise for placing it as an accent to any character in a font in this sort of way, there is no guarantee that it is perfect for any particular combination. c) If "\[vs]" is defined as a composite character using groff code (like the code in the "acc" module of s.tmac -- see recent posts), then whether the placement of the hacek is perfect depends on details of the code:-- is it fine-tuned for this particular combination? On the other hand (as in the old way of making accented characters) the groff code is as crude as the "overstrike" method above, then ov course the two would be identical, and may or may not be good. d) If you want "perfect" results, then ideally, when defining groff code for composite characters, you should define each character individually and fine-tune the positioning. Whether you need to do this for any particular composite character depends on how well they fit together without fine-tuning: you can only judge this by eye! Hoping this helps, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 07-Mar-06 Time: 16:46:01 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: Composed glyphs - quick and dirty solution
On 06-Mar-06 Werner LEMBERG wrote:
>> > Again, I've no idea :-) The code snippet was taken from ps.tmac,
>> > without analyzing it in detail. I've simply forgotten how it
>> > works.
>>
>> The answer here is (or should be) that if you place an accent over a
>> "skew" character (e.g. italic), you need to offset it slightly to
>> the right so that it is above the top side of the glyph and not the
>> horizontal mid-point (which is what would happen without taking
>> account of skew). So you need the skew of the "under" glyph to
>> compute this; and the skew of the "over" glyph is (in most cases)
>> not relevant.
>
> Thanks -- I was aware of this fact. With `forgotten' I've meant just
> the details of the macro, not how skewing in general works.
>
> Maybe proper accent macros can be based on `acc*over-def' and friends
> from s.tmac. They could be moved into a separate macro file and
> adapted for general use.
Sorry, Werner, I misunderstood what you were saying, since it seemed
to be a direct reply to Michail Vidiassov's question "Why the skew
is computed for 'x' and not for accent glyph ('\\$2')?" , which is
what I explained!
Anyway, thanks in turn for remining me of what I had in my turn
forgotten -- namely that all my accented-character work uses the
ms accent definitions in the "module acc" ("accents and special
characters") in s.tmac, with a much extended ".AM" macro.
I would indeed recommend this code to people who need to create
composite characters which are not otherwise catered for.
Best wishes to all,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 06-Mar-06 Time: 09:52:06
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] More arguments, please :-)
On 10-Mar-06 Miklos Somogyi wrote: > I've just discovered the `blm' macro. I think that I'll use > it like this: > > .blm sp4 > > .de sp4 > .sp .4 > .. > > 'cause I can read thing better with blank lines than with individual > `.sp .4` inserts. > Here blm has an argument, a macro. If the macro could have an argument > too: > > .blm macro macro_parameter > > then it would be absolutely easy to adjust the bottom of the page to go > down right to the margin. Perhaps the whole thing could be automated. > > Is there a way to make an offer to blm that it can't refuse, to accept > one more argument? > Is this adjustment thing I am dreaming about already solved in any > other way? I think the only way you can do it is on the following lines: .de mysp .sp 4 .. .blm mysp and then you can simply redefine 'mysp' whenever you like, without redefining 'blm'. This is almost as compact as redefining .blm sp 6 say, every time. Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 10-Mar-06 Time: 21:51:37 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] PS printing - was Re: `Idot' vs. `Idotaccent'
On 10-Mar-06 Michail Vidiassov wrote: > Dear All, > > let us run some survey. > Please, tell us, how do you use groff PS output. > Do you know how other people use it? > Is it really in use? > Do you use fonts supplied with groff or install your own font files? > > Werner is now desiding what to consider the default font set for devps. > > Sincerely, Michail I've been watching this thread with a little concern. Regarding Mikhail's final remark, I would like to say that, whatever additional fonts become available with groff, the standard Adobe fonts should remain the default. Otherwise, too many things created in the past will break. Also, they are de facto defaults in many other contexts outside groff, and all PS-enabled printers etc. include them (either as true Adobe fonts or as aliases to the manufacturer's own versions of similar fonts). In answer to the other questions: 1. I use groff PS output a) for printing to a PS printer b) for display (with ghostscript, ghostview, etc.) c) for creating PS files to be converted to PDF d) to create EPS files ... 2. "Other people" use it for all sorts of things. Basically for anything you can use a PS file for! 3. I'm not sure if I really understand the question, but if there is an implication that people don't really use groff PS output any more, then my emphatic ansers is a) YES it is really in use! b) NO it is not going obsolete! 4. The groff fonts are not "supplied with groff" -- all you get is the description files which define the metrics, kerns, and the groff names of the characters. The apparent exceptions (symbolsl.pfa, zapfdr.pfa) are simply tiny files which define transformations on the Symbol and Zapf Dingbats fonts which are presumed to be already available in the printer or display device, and are not supplied as fonts. I normally use simply the standard groff fonts (i.e. the same as the Adobe standard fonts plus SS and ZDR); but I have also installed some additional fonts (additional type faces corresponding to standard fonts, plus some additional different fints such as Cyrillic and IPA). I use whatever is needed by the task in hand. So I do both: a) use the standard fonts; b) install my own. I'd be grateful for clarification of where people think this discussion is heading. And why. Best wishes to all, Ted. ---- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 10-Mar-06 Time: 22:12:32 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Re: Composed glyphs - quick and dirty solution
On 04-Mar-06 Werner LEMBERG wrote:
>> Why the skew is computed for 'x' and not for accent glyph ('\\$2')?
>
> Again, I've no idea :-) The code snippet was taken from ps.tmac,
> without analyzing it in detail. I've simply forgotten how it works.
The answer here is (or should be) that if you place an accent
over a "skew" character (e.g. italic), you need to offset it
slightly to the right so that it is above the top side of the
glyph and not the horizontal mid-point (which is what would
happen without taking account of skew). So you need the skew of
the "under" glyph to compute this; and the skew of the "over"
glyph is (in most cases) not relevant.
Without this, "italic c circumflex", say, might not look too bad;
but "italic l circumflex" would look terrible.
Best wishes to all,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 04-Mar-06 Time: 20:34:45
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Adding fonts to groff -- instructions?
In view of the current discussion on installing PS fonts in
groff, I am reposting a method which I originally posted
back in 2000.
This is a "bare hands" method, which can be applied even for
fonts with nasty encodings. It was originally posted in
connection with installing IPA ("International Phonetic
Alphabet") fonts, and is formulated in appropriate specific
terms. However, subject to changing certain specific terms
(which will be obvious below), it will work for any font.
And indeed I generally use it for anything, rather than
the script that comes with groff.
Hoping this is useful,
Ted.
How to install a font (IPA as example)
==
The best I have found are Hoekwater's XIPA fonts which you can find
on the CTAN TeX archive, somewhat obscurely buried at
ftp://tug.ctan.org/tex-archive/fonts/tipa/beta0624/ps-type1/hoekwater/
where the file hoekwater.zip contains five "Adobe-Type-1" phonetic fonts:
XIPA10 Like Times Roman
XIPASl10Like Times Italic
XIPAB10 Like Times Bold
XIPABX10Similar to the preceding, but perceptibly and subtly different
XIPASS10Sans-serif (like Helvetica)
Each font has 256 characters at encodings 0-255 (including 127 and 255).
They install cleanly using the groff mechanism. However, for such a
font (where the "groff name" you might want to give a character my
not be obvious) I install these with a null mapfile. This has the effect
that the groff font file gives "---" as the groff name for every
character, so that it can only be accessed with a \N sequence, e,g,
\N'195' for the thing that looks like a composite "dz". You can then,
at any later time, invent your own names for the things you need, e.g.
.char \[dz] \N'195'
(which I would do in a ".IPA" macro similar to the one I posted
earlier for small caps).
The procedure I use for installing such fonts (which is manual,
I don't trust scripts for these one-off jobs) is appended, customised
for a typical XIPA font.
Ted.
===
Procedure (using XIPA10 as an example):
1. Park the files in a safe directory.
2. If you only have .pfb, Run
pfbtops xipa10.pfb > xipa10.pfa
thereby making an ASCII .pfa font file.
3. Look at this .pfa file and get the font /FullName which in this
case is
xipa10
Note this down.
4. For this particular application, make yourself a null (empty)
mapfile:
touch null_mapfile
(Normally, the mapfile gives pairs PS-name groff-name but
IPA is so nasty it's better to leave this issue aside at this stage).
5. Choose a name for the groff font file (which will go in devps).
I just used
XIPA10
and similarly for the others; but you could choose IPA_TR, IPA_TI etc.
or whatever else you like.
6. Now (here and below I'm using my own directory path to devps/ ;
you use yours)
afmtodit -d/usr/share/groff/font/devps/DESC \
xips10.afm null_mapfile XIPA10
(all on one line as indicated by the \ )
7. Copy XIPA10 to /usr/share/groff/font/devps/
8. Copy xipa10.pfa to /usr/share/groff/font/devps/
9. Edit /usr/share/groff/font/devps/download to add an entry
xipa10xipa10.pfa
(using what you noted at (3))
10. Edit /usr/share/groff/font/devps/DESC as follows:
a) increment the font-count by 1 (the number immediately after
"fonts" in the line starting "fonts");
b) append the fontfile-name XIPA10 to the list of fonts in the
same line.
11. TEST IT!
===========
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 284 7749
Date: 09-Aug-00 Time: 12:59:42
-- XFMail --
___
Groff maillist - [EMAIL PROTECTED]
http://ffii.org/mailman/listinfo/groff
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 11-Mar-06 Time: 21:14:05
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Looping and printing indices in groff
On 13-Mar-06 Robert Marks wrote: > Having installed a new font, I now want to print all characters. > I thought of having a loop: > > for i=1 to 350 do X > "i" "\N'i'" > X > > But this won't work, of course. > How can I do such a thing? .nr NN 0 1 .while \n+[NN]<255 \n[NN]\0\N'\n[NN]'\0\0 is one way. Best wishes, Ted. ------------ E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 13-Mar-06 Time: 12:54:01 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Adding fonts to groff -- instructions?
On 13-Mar-06 Robert Marks wrote: > Ted suggests adding the font to /font/devps/DESC (see below). > What is the purpose of this? > I haven't done it and things seem to work, but perhaps I'm missing > something. > >>From: (Ted Harding) <[EMAIL PROTECTED]> >>Subject: RE: [Groff] Adding fonts to groff -- instructions? >> >>10. Edit /usr/share/groff/font/devps/DESC as follows: >> >>a) increment the font-count by 1 (the number immediately after >> "fonts" in the line starting "fonts"); >>b) append the fontfile-name XIPA10 to the list of fonts in the >> same line. Only the font *name*, of course. The effect of including the font name in the "fonts" line of the DESC file is to enable font-position numbering for that font. It has no other purpose as far as I know, and if it is irrelevant for you then I suppose it does no harm to leave it out. However, doing so has no adverse effects, and if you ever should need position numbering then it is available if you have already added it. So why not? Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 13-Mar-06 Time: 14:37:08 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] gtroff & soelim don't recognize ~ in paths
On 09-Apr-06 Larry Kollar wrote: > Sourcing a file like this: > > .so ~/Library/XSL/html2ms.xsl > > Using either straight groff or soelim, I get the message: > ./single.ms:207: can't open `~/Library/XSL/html2ms.xsl': No such file > or directory > > It works with an explicit path. Is this a bug or a feature? Neither! The "~" character is a "shell special", and depends on the shell for "tilde expansion" [I'm talking Unix/Linux here; I have no idea how Windows handles this sort of thing, if at all]; for example. "man bash" says: Tilde Expansion If a word begins with an unquoted tilde character (`~'), all of the characters preceding the first unquoted slash (or all characters, if there is no unquoted slash) are considered a tilde-prefix. If none of the characters in the tilde-prefix are quoted, the characters in the tilde- prefix following the tilde are treated as a possible login name. If this login name is the null string, the tilde is replaced with the value of the shell parameter HOME. If HOME is unset, the home directory of the user executing the shell is substituted instead. Otherwise, the tilde- prefix is replaced with the home directory associated with the specified login name. So when such a thing is processed by the shell (in a command line or a shell script), the above expansion takes place. However (though without checking) I should think that when any of the 'groff' programs executes code which references a filename, it goes straight to the kernel for the file (and I know from C experience that the default "root" for names not beginning with "/" is the working directory), and bypasses the shell. Hence in .so ~/Library/XSL/html2ms.xsl the "~" is not expanded by the shell (since the shell does not see the line) and so the kernel looks for a directory named "~" in the working directory, fails to find it, and reports as such. I think the is correct in principle, though I'm not sure about some of the implied detail. Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 09-Apr-06 Time: 08:45:34 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] PDF printing coming
On 21-Apr-06 Michail Vidiassov wrote: > Portable Document Format (PDF) is set to displace PostScript > as the standard print job transfer and processing format for > Linux, though Linux will maintain PostScript support for a > long time to ensure backward compatibility. > > This switch was agreed upon at last week's Linux Desktop > Printing Summit. Open Source Development Labs (OSDL) and > Linuxprinting.org organized the meeting, which was hosted > by Lanier (a Ricoh corporation) at its Lanier Education > Center in Atlanta. At the meeting there was virtually no > disagreement about the change. > > The fine details will have to be thrashed out over the coming > months, but representatives from CUPS, Ghostscript, > Linuxprinting.org, KDE, GNOME, hardware vendors (present were > people from Epson, HP, IBM, Lanier, Lexmark, Ricoh, Sharp, and > Xerox), and developers of free drivers all agreed that PDF > will give them more power, more reliability, and more control > over the printing process. > > http://applications.linux.com/article.pl?sid=06/04/18/2114252 > > Are we ready? Very interesting, and I had no idea of this until you told us! Thanks! I am perturbed by some of the implications, however. Never mind "backwards compatibility". As things stand at present, PS has advantages over PDF. For one thing, you can write your own PS file from scratch using a text editor. And you can edit any PS file (except for those which have been encrypted, which is unusual, or depend on Hex encoding for graphics blocks etc.). PS is at bottom a plain ASCII format. On the other hand, I've never seen a PDF file that I would want to even think about editing by hand; and while it may be in principle possible to create one by hand I don't think I would like to try that either. The plain fact, in real life, is that editing or creating a PDF file requires specialised software which, to the non-specialised user (including users who could cope with editing PS), is simply a black box. I grant that PDF has resources which PS lacks (the need for PDFmarks in PS which is to be converted to PDF for some of these is proof of that). In my view, the main reason for the emergence of PDF as a "standard" has little to do with these extra resources, however. I think it is due to the fact that PDF files can readily be read on Windows platforms (provided you have the free Acrobat reader, of course), and can also be edited if you have bought the appropriate Adobe software. On the other hand, Windows support for PS has always been grudging at best: you can in the limit import an EPS "graphic" into a Word document, but you can't view it on screen, and you can only print the result successfully on a PS printer. (And when I say "graphic", the EPS could of course simply be text). And heaven help you if you try to edit a PS file in Word ... So, for the sake of making our PSs available to the challenged out there, we have happily converted them to PDF; and the challenged are none the wiser since it still looks good. I harbour fears that this proposed move towards PDF as the standard indicates an impending domination of the capable by the challenged. My only consolation is that, according to Michail's account above, it will be (at peast partially) in good hands; though the evident involvement of commercial interests -- even at the basic level of organisating the meeting -- causes me some disquiet. I'm well aware (being one of them myself) that many people on this list are there because they are survivors from the Age of the Dinosaur (ca. 30 years ago). Unix and troff had shown how things could be done properly, leaving the user still in full control and with easy direct access to the "internals" to achieve such control. Shortly afterwards, PostScript emerged and supplanted the Optical Daisywheel (aka CAT Phototypesetter), and extended that control beyond the computer to the output itself. We liked the way we worked then, and we like it still; and the emergence of Linux has maintained that distinctive way of working and made it available to a much larger userbase. And I think we have been able, to this day, to feel happy about the better performance and capabilities of this way of working. But, in my view again, somewhat unfortunately Linux has increasingly yielded to the gravitational pull of the Windows world. Increasingly, with the adoption of Office-type software suites, the user's output is encapsulated in an impenetrable format, and the control the user has over this is becoming increasingly remote. I fear that the above move from PS towards PDF may bring similar disadvatages with it. Unless, of course, we can gain the same control over PDF as we have over PS (see above). Just my thoughts ... Best wishes to all, Ted. ---
Re: [Groff] PDF printing coming
On 21-Apr-06 Peter Schaffter wrote: > Ted -- > > On Fri, Apr 21, 2006, Ted Harding wrote: >> I harbour fears that this proposed move towards PDF as the >> standard indicates an impending domination of the capable >> by the challenged. > > Is "domination of the capable by the challenged" your own phrase? > It's terrific, and I'd like to be able to attribute it properly. Well, I suppose it is, since I wrote it spontaneously! But that's not to say that someone else may not have used it before -- it's a situation that needs a phrase! All best wishes, Ted. -------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 21-Apr-06 Time: 16:13:11 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Survey on Document Creation Software
On 02-May-06 Robert Marks wrote: > groff/troff/nroff is languishing even against KOffice and GNOME > Office (AbiWord etc), at only 2% (37 votes). We're not going to knock > off TeX, but surely readers of this list are more numerous than that! > > Go to > http://www.cups.org/ > to vote for your favourite. Well, with 52 votes just now [3%], groff now weighs in at No 3 (after OpenOffice with 878 [53%] and TeX with 507 [31%]), if one excludes "Other Commercial". Best wishes to all, Ted. ------------ E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 02-May-06 Time: 13:52:06 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Math symbol upside down?
On 06-May-06 Clarke Echols wrote: > I am playing around with a little project and decided to make a > drawing using groff accompanied by mathematical analysis text. > > I decided to use the \(~= sequence for the "approximately equal" > symbol in the math table, using the eroff manual I have from the > late 1980s as a reference. In that manual, the symbol is a > horizontal bar with a tilde bar above it, but in the groff package > I got with cygwin, the tilde is on the bottom. My PostScript > tutorial by Ross Smith indicates that the math font character is > actually a pair of tildes. > > What's going on? I've never seen a tilde on the bottom before. > Is this a take-off spoof like GNU's not Unix? :-) > > Clarke Hmm, I'm not sure where you are getting this result from. Check out .../devps/S and you should find that both \(~= and \(~~ map to PostScript "approxequal" which is your "pair of tildes". Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 06-May-06 Time: 07:46:37 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Math symbol upside down?
On 06-May-06 Clarke Echols wrote:
> Oops --
>
> The problem appears to be in Ghostgum/ghostscript and how it
> displays. If I increase the point size substantially, I get
> the double tilde that I want, but when I set it at 12 points,
> it *appears* to be a straight line with a tilde underneath,
> except for a slight crook at the end of the straight line.
> Evidently it's a screen resolution problem (though I use a large,
> high-resolution display).
>
> Sorry about the false alarm... I keep forgetting that interpolation
> of pixel locations can lead to such anomalies.
>
> Thanks for the response. I was not aware of the \(~~ escape
> sequence.
>
> Clarke
Ahhh! I use ghostview ('gv') for viewing PS files, and (a) you
can set an option for antialising (which gives much better visual
resolution of curved boundaries); (b) you can change the zoom
factor on the fly; (c) if you really want to see what's going
on at a particular place you can outline it with the mouse and
zoom it up.
Well, it's good that the problem got solved!
Best wishes,
Ted.
------------
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 06-May-06 Time: 16:45:01
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Meeting Werner
On 09-May-06 M Bianchi wrote: > It was great to read the interview with Werner (our Fearless Leader?). > What an interesting story! It is good to "meet" you, Werner. > > Now all we need is a Groff Anthem to be sung at the next International > Groff Confernece ;) So long as it's an improvement on the "Free Software Song" -- see: http://www.gnu.org/music/free-software-song.html whence you can download it in .au or .ogg format. But Werner's background encourages me to anticipate a higher level of inspiration! Best wishes to all, Ted. -------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 09-May-06 Time: 14:08:49 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Meeting Werner
On 10-May-06 Werner LEMBERG wrote: > >> > We also have the slang word `grotty', with similar meaning, and >> > presumably from the same Germanic root; in a `groff' context, the >> > connotation is somewhat unfortunate :-) >> >> You think you have a problem. I must be one of the few people named >> after a groff program. > > Hehe. It's not only you -- the very problem why we don't have a > `groff.org' is that this domain is owned by a person called Dana > Groff. Actually, he (or she?) just owns that domain, with a basically > empty web page. Probably only the associated email address is really > in use. Try a ggogle search using "groff family" ... there are more about than one might think! Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 10-May-06 Time: 07:46:38 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Meeting Werner
On 10-May-06 Ralph Corderoy wrote: > > Hi Werner, > >> Hehe. It's not only you -- the very problem why we don't have a >> `groff.org' is that this domain is owned by a person called Dana >> Groff. Actually, he (or she?) just owns that domain, with a basically >> empty web page. Probably only the associated email address is really >> in use. > > She's a she I think, "dana at groff.org". http://www.groff.org/dana/ > is the way into the site. I had to `Select All Text' to make the > resume readable. Compare this resumé with the lead article at http://blogs.msdn.com/chkdsk/ "MSDN Webcast: The Revolutionary Windows Vista Transactional NTFS (TxF) Infrastructure" "Presenter: Dana Groff, Program Manager, Microsoft Corporation" "Dana is the program manager (PM) in Core File Services team at Microsoft, focusing on transaction technologies. As the PM for Transactional NTFS (TxF), the Kernel Transaction Manager, and Common Log File system, he coordinated building this new kernel transaction infrastructure for Longhorn ... " and it zeems likely that they are the same person -- and a "he"! Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 10-May-06 Time: 09:13:58 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Inline evaluation of calculations?
On 11-May-06 Larry Kollar wrote: > I was wondering if there was a way to, for example, print the result > of \n%+1 without using a junk variable. I didn't see a request > equivalent to "eval" in the manpages or the texinfo thing. Hi Larry, I'm not aware of one either (though of course the "junk variable" method works fine). You could of course define a macro/parametrised string on the lines of .de eval .nr Neval \\$* \\n[Neval] .. The value of \en%+1 is .eval \n%+1 (correct since this is page 1). which produces the output The value of \n%+1 is 2 (correct since this is page 1). Best wishes, Ted. ------------ E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 11-May-06 Time: 19:18:46 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Sun's troff now available
On 24-Jun-06 Larry Kollar wrote: > I stumbled across this today, and didn't see anything about it in the > archives. > > http://heirloom.sourceforge.net/doctools.html > > "The Heirloom Documentation Tools package provides troff, nroff, and > related utilities They are portable and enhanced versions of the > utilities released by Sun as part of OpenSolaris, which are a variant > of ditroff, which, in turn, descends to the historical Unix troff > that generated output for the C/A/T phototypesetter." > > There might be something worth cherry-picking. :-) Fascinating, Larry! There are some interesting things illustrated in the PDFs on the site -- see e.g. http://heirloom.sourceforge.net/doctools/troffdemo.pdf http://heirloom.sourceforge.net/doctools/fonts.pdf Thanks. Ted. ------------ E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 24-Jun-06 Time: 10:06:23 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Sun's troff now available
On 25-Jun-06 Peter Schaffter wrote: > On Sun, Jun 25, 2006, Werner LEMBERG wrote: >> .fzoom >> >> Apply a scaling factor to a font. Useful to harmonize the size >> of different fonts like Times and Helvetica if simultaneously. > > Brilliant. Also very useful is one (say) interpolates Courier font with Times Roman (as for example when referring to program names), since the usual fonts for CR and TR don't nicely match visually in size. >> .minss >> >> Minimum word space when adjusting lines. I consider this a quite >> elegant solution to circumvent the problem of not having >> shrinkable whitespace in groff. > > This one would be a good start, but it's not enough for top-quality > typesetting. I've written on this before. Groff needs a > line-adjusting mechanism that takes both word- and letter-spacing > into account. Ideally, the two would be both stretchable and > shrinkable, although shrinkable appears to be out of the question. This triggers an issue which I've been thinking about for a while without managing to get a proper handle on it in the code. A number of issues (and the one raised by Peter is an example) in groff formatting could be solved provided, once an output line has been fully formatted and is about to be output, one could then access that object and perform some final tweaks to it before it is actually sent out. At present, this last stage takes place within a black hole in groff, and the user cannot intervene. The example which first prompted me to think about it was the problem of continuous underlining (since then nicely solved by Werner by other means). There is no particular difficulty in drawing an underline from the left margin to the right margin for a line which needs underlining in its entirety; but when the underlining starts in the middle of one line, and ends in the middle of another, then one needs to know the position in the output line of the character where it starts or ends. This is implicitly stored in the finally-formatted output-line object. > [Peter's fascinating tour of the Typesetting Museum snipped] > It doesn't sound terribly sophisticated, yet it worked well enough > to satisfy even the most demanding designers and proofreaders. I > wonder why, even working within groff's limitations, a similar > (though obviously not identical) line-adjusting procedure isn't > used. At present, groff's line adjusting mechanism requires a > huge amount of manual intervention to achieve what was being done > automatically on rickety old Quadriteks three decades ago. I have to agree with this. Whenever I have wanted to produce fine-tuned output, I wait until I'm sure the document is in final form. I then go back to the troff source, and re-format this text file so that there are line breaks in the troff source where there are also line breaks in the printed output. At this stage, of course, this re-fromatting has no effect on the layout of the printed output. Then you can interpolate troff requests/macros to make the adjustments you want, on a line-by-line basis, where needed. Indeed, prior to Werner's underining macro, this is how I used to deal with the continuous underining issue. And you can also deal with the "hanging characters" problem in this way too. Once again, I suspect that all this kind of thing could be helped by pre-output access to the finally formatted output line (since the mechanism I describe above amounts to this, but riding a mule to climb the mountain rather than taking the helicopter). Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 26-Jun-06 Time: 10:34:03 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Sun's troff now available
On 26-Jun-06 Peter Schaffter wrote: > On Mon, Jun 26, 2006, Ted Harding wrote: > [...] >> Once again, I suspect that all this kind of thing could be >> helped by pre-output access to the finally formatted output >> line (since the mechanism I describe above amounts to this, >> but riding a mule to climb the mountain rather than taking the >> helicopter). > > Good analogy. > > FWIW, back in the Museum, even though galleys were set from > what amounted to "source files", the workstations had a > continuously updating "status line" that told you exactly where > you were, both vertically on the galley and horizontally on the > currently-being-input line (measured from the position of the cursor > in the input text). By keeping an eye on the status line, you could > make a lot of judgment calls concerning where to break troublesome > lines, how much kerning to apply, etc. during the first run. > > I'm wondering if this is the kind of "pre-output access" you're > envisaging. Hard to imagine how groff could implement it in > user-space, nice though it would be. Seems to me it would require a > specialized front end. Sort of, I think -- though it looks as thought you're seeing the status line prior to, or while, the output is still being formatted. The sort of thing I have in mind is targeted right at the line which is about to be output, as follows lines. Suppose you have formatted output lines (say, as you mentioned, in a narrow-column context) like: This formatted line needs smaller spaces. So track kern- ing can be used to reduce them. If you had a "pre-output" macro (just as you can have macros which are sprung by bottom-of-page, so you could have macros sprung by "about to output line"), then this could look at a) Inter-word spaces: if larger than a threshold, expand the inter-character space until these are reduced below it. b) Is there an end-of-line character (like the soft hyphen above, which might not have been explicit in the source) which we would like to hang over the end of the line? Then slightly increase the linelength of this line (or redefine "-" to have smaller width, or whatever) so that it sticks out by the right amount. c) Similar for "\(lq" at the start of an output line or "\(rq" at the end, hanging punctuation, etc. ... The end result would probably be acceptable in most cases, and would have been created automatically, so there's no need for extra work during the draft phase. Once the document is in final form, you can then read it through and, for those relatively few cases where it still needs adjustment, use the bare-hands methods we've been describing. However, if all has gone well (which depends on well-tuned design of the "output-line" macro), the extra work involved in this would be a small fraction of the work to do it all by hand. Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 26-Jun-06 Time: 19:06:14 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Sun's troff now available
On 27-Jun-06 Peter Schaffter wrote: > On Mon, Jun 26, 2006, Ted Harding wrote: >> > FWIW, back in the Museum, even though galleys were set from >> > what amounted to "source files", the workstations had a >> > continuously updating "status line" > >> > I'm wondering if this is the kind of "pre-output access" you're >> > envisaging. > >> Sort of, I think -- though it looks as thought you're seeing the >> status line prior to, or while, the output is still being formatted. >> The sort of thing I have in mind is targeted right at the line which >> is about to be output, as follows lines. Suppose you have formatted >> output lines (say, as you mentioned, in a narrow-column context) >> like: >> >>This formatted line needs >>smaller spaces. So track kern- >>ing can be used to reduce them. >> >> If you had a "pre-output" macro (just as you can have macros which >> are sprung by bottom-of-page, so you could have macros sprung by >> "about to output line")... > > But this is brilliant! At least, if I understand you. It sounds > as if you're talking about an end-of-line trap--something sprung > at the end of every line rather than having to be set. If such a > "trap" existed, macro writers could attack the problem of letter-and > word-spacing themselves. This has many advantages over trying to > implement code in groff to do the same thing, methinks. That's *exactly* what I mean, Peter! > Wonder if it's doable? So do I! I've had a look at the code, but didn't see a hook for it. (Which doesn't mean it isn't there -- perhaps I'll have another look). Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 27-Jun-06 Time: 09:46:18 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Spam
On 01-Jul-06 walter harms wrote: > hi people, > i get a bunch of spam since a few days via this list. > > Am i the only one or have some more people seen spam also ? > > re, > wh I should think everyone has. And not just the last few days. Last Thu-Fri (22-23 June) I got 12 such messages. Then Tue-Wed (27-28 June) I got 17 of them. I also received a number later in the week but simply deleted them without inspection. All the above-itemised emails were sent to the list with "From:" addresses like Williams <[EMAIL PROTECTED]> with various other names also in place of "Williams", like "Darla", "Dave", "Molly", "Harriet" ... , but they all have "[EMAIL PROTECTED]". Of course, "[EMAIL PROTECTED]" is our Werner Lemberg, which is why these messages were allowed through to the list, since Werner is of course subscribed to the list. These "From:" addresses are of course forged, and no blame whatsoever can be attributed to Werner. But this forgery also means that it is impossible to prevent them coming through to the list -- unless perhaps (in view of their content) they could be trapped by a spam-filter. Whether that is a reasonable option is something for the list managers at gnu.org to consider. For what it's worth, during the second phase (27-28) above, I also received additional copies of some of these directly to my email address (i.e. not via the list). For example: From: Cecile <[EMAIL PROTECTED]> To: groff@gnu.org Subject: [Groff] prOblems with meds expencies, you Are On right way From: Cecile <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: prOblems with meds expencies, you Are On right way Note the interesting comparison between the two "From:" addrsses. And there is no such user as TNkX on nessie.mcc.ac.uk They were received directly by gnu.org from some 16 different IP addresses (the ones sent directly to me also being from these addresses), and the typical relevant header is: Received: from [253.21.8.247] (port=3275 helo=253.21.8.247) by gnu.org with esmtp Received: from [253.21.8.247] (port=9752 helo=253.21.8.247) by gnu.org with esmtp etc., so it looks as though gnu.org is allowing them in without attempting a reverse DNS lookup -- and indeed, though I have not checked every case, the 6 or so I have checked do not resolve. Hence, I wonder if this amouts to gnu.org acting as an open relay? Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 02-Jul-06 Time: 16:50:39 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] making tbl created tables fit on the paper
On 04-Jul-06 Gabriel Diaz wrote:
> Hello,
>
> I wonder what kind tricks you use to make big tables that goes beyond
> the paper defined boundaries fit on the paper.
>
> How you mangae to fit them? Just changin the point size?
That, and other things! You can use the numeric flag to reduce
the "blank space" (default = 3n) between columns. For example
.TS
l2 l2 l.
where instaed of "2" you can have "1" or even (in extreme need) "0".
However, with "0" there will be no space at all, so if entries will
the width of the columns you will need vertical lines to separate them.
You can also try (for text) setting a reduced inter-word space,
setting the end-of=sentence space to 0, setting a slightly negative
track-kerning (so the letters get a bit closer together), using
the \W (if you're output is PostScript) to make the characters
slightly narrower), etc. But these things can only make a small
percentage difference (maybe up to 15%).
You can also temporarily reduce the left margin (page offset)
and increase the line length (which has the effect of reducing
the right margin), so that the table goes outside the normal
boundaries, but in a nice way.
Another thing to think of doing is to set the table in landscape
orientation, though this usually means you need to set aside a
whole page for it.
> I use the mm macro and in the tables i use the T{ T} to quote text.
> But still i need to reduce it more.
>
> Any tips would be appreciated.
If you could give us a clearer picture of the table layout and of
the extent of excess, that might help to focus ideas.
Best wishes,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 04-Jul-06 Time: 12:01:59
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] Rules drawn with \D are rounded
On 09-Jul-06 Peter Schaffter wrote:
> I've been contemplating adding some macros to the mom set to
> ease the creation of simple graphical objects: rules, boxes and
> elipses/circles ("ease" meaning "make easier for newcomers to
> groff").
>
> However, I've discovered something troubling: rules drawn with
>
> \D'l '
>
> have rounded caps; the ends of the rules are not straight.
>
> Equally, unfilled polygons drawn with
>
> \D'p
>
> all have rounded corners, whereas filled polygons drawn with
>
> \D'P '
>
> produces the expected "sharp" corners.
I hadn't spotted that difference! Good to have it pointed out.
> Typographically speaking, this is not an expected, or--in my
> experience--justifiable default behaviour for rules and polygons.
Agreed.
> The effect is scarcely noticeable with narrow rule weights
> (i.e. < 1000 units), but when the rule weight increases the effect
> becomes more and more pronounced.
>
> So, the usual questions:
>
> 1. What is the rational behind groff's drawing rounded caps on
> rules, and rounded corners on unfilled polygons?
I don't know but I set out some considerations below.
> 2. Can this behaviour be changed in user space?
Yes. There are raw PostScript commands, 'setlinejoin', 'setlinecap'
and 'setmiterlimit' relevant to it (info quoted from the PostScript
Language Reference Manual or "Red Book"):
\X'ps: exec n setlinejoin'
where
n=0: Miter join--the outer edges of the strokes for the two
segments are extended until they meet at an angle ...
If the segments meet at too sharp an angle, a bevel
join ["n=2" below] is used instead. This is controlled
by the the 'miterlimit' parameter established by
'setmiterlimit' [for which see Red Book]
n=1: Round join--a circular arc with diameter equal to the
line width is drawn around the point where the segments
meet and is filled in, producing a rounded corner.
'stroke' draws a full circle at this point. If path
segments shorther than one-half of the line width meet
at sharp angles, an unintentional "wrong side" of this
circle may appear.
n=2: Bevel join--the meeting path segments are finished with
butt end caps [as with "n=0" for 'setlinecap' below];
then the resulting notch beyond the ends of the segments
is fille with a triangle.
\X'ps: exec n setlinecap'
where
n=0: Butt cap--the stroke is squared off at the endpoint
of the path. There is no porjection beyond the end
of the path.
n=1: Round cap--a senicircular arc with diameter equal
to the line width is drawn round the endpoint and
filled in.
n=2: Projecting square cap--the stroke continues beyond
the endpoint of the path for a distance equal to
half the line width and is squared off.
So for single lines with square ends, you should '0 setlinecap';
I can't think of a good reason for round ends on rules--it may
be that this is the PS default (though I can't see this stated
in the Red Book). For rules in tables, again '0 setlinecap'
normally except where the ends of horizontal and vertical rules
meet at right angles, when you need '2 setlinecap' provided
the lines are of the same thickness (it may be that this little
complication is the reason for rounding the ends of rules.
For polygons (filled or unfilled), normally '0 setlinejoin'.
This can produce unwanted results with sharp angles and thick
lines, but I can't otherwise think of a reason for using round
joins as a default nor for unfilled as opposed to filled
polygons.
The current values of the relevant parameters can be accessed
in PS by 'currentlinejoin' and 'currentlinecap' etc.
Hoping this helps
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 10-Jul-06 Time: 09:16:11
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
[Groff] groff on GNU
Hi Folks, Visiting http://www.gnu.org for a quite separate purpose, I started to browse in the FSF "software directory": http://directory.fsf.org/ and began to wonder where to look for groff. The list of categories is not particularly helpful, but I explored by burrowing down through Text creation and manipulation -> Documentation tools and there is groff -- described as "Document formatting system". There also is LaTeX -- described as "Typesetting system". I feel groff is a bit slighted by this, since it is as much a typesetting system as LaTeX is! I suspect that the groff description carries the burden of groff's role in formatting man-pages, i.e. supporting Unix-style documentation, which masks its true merits as a typesetting system. I feel this should be changed! Best wishes to all, Ted. -------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 13-Jul-06 Time: 20:23:07 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] groff on GNU
On 13-Jul-06 Werner LEMBERG wrote: > [about the contents of www.gnu.org] > >> I feel this should be changed! > > Please go forth and submit changes to the website maintainers! > > Werner OK, will do! Ted. ------------ E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 13-Jul-06 Time: 21:20:31 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Line length and page offset in MS
On 26-Jul-06 Robert Goulding wrote: > On Jul 26, 2006, at 11:23 AM, Ulf Bro wrote: > >> Hi, >> >> With Groff 1.18.1 I seem to not be able to set line length >> and page offset with the .PO and .LL commands. Whatever I >> set in the input file the document produces a neat output >> file with something like 1 inch margin. Am I doing >> something wrong. I have SuSE Linux 10.1. >> >> Ulf > > This was a bug in older versions of the groff ms macros. > I can't remember when it was fixed - but it is certainly fixed > in the current version. Either upgrade, or use the .po request > as well as the PO register. > > Robert I'm not sure it should be dismissed as a bug. That was certainly the behaviour of other versions of troff in the older days (e.g. I remember it from sqtroff in the 1980s), and it may well go back to Unix troff. The point is that (in versions where this behaviour occurs), when the first page is initialised (ms macros having been read in before anything happens), the page number \n[PO] register is initialised to the value of \n[.o] and the line length \n[LL] (if not already defined) is intialised to 6i. These are then saved to "backup" registers. Then, every time a new page occurs, \n[PO] is reset from the backup register; likewise, whenever a new paragraph occurs, \n[LL] is similarly reset. Hence the work-round which Robert suggests: if you want non-default values of \n[PO] and \n[LL], you do (e.g.) .po 3c \"instead of default 1i .nr PO 3c \"or .nr PO \n[.o] .ll 12c \"instead of default 6i .nr LL \n[.l] (I have never thought twice about this -- at least not for a very long time -- since I got into the habit of it with sqtroff back in 1984). best wisyhes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 26-Jul-06 Time: 22:11:27 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] patch for pdfroff
On 31-Jul-06 Werner LEMBERG wrote: > On 31-Jul-06 Keith MARSHALL wrote: >> Since it's just a bit of light hearted fun, I probably won't. I >> can't access that site from here -- blocked by firewall -- but I'll >> have a look later. > > Ok, it's now here: > > http://groff.ffii.org/groff/temp/teapot.ms.tar.gz > > Werner A delightful piece of research! (Is that your photo in Fig. 9, Keith?) However, the report indicates a certain naivety of methodology, despite the ultimately decisive outcome and the satisfying spin-off from the research. To find out how to do such things properly, I recommend as a definitive example the instructions contained in British Standard 6008 (BS 6008:1980, ISO 3103:1980): "Method for Preparation of a liquor of tea ... ", of which a PDF copy can be found at http://ftp.ee.surrey.ac.uk/papers/AI/L.Gillam/bs_tea.pdf Best wishes, Ted. -------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 31-Jul-06 Time: 17:04:43 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] patch for pdfroff
On 01-Aug-06 Keith MARSHALL wrote: > Ted Harding wrote: >> I recommend as a definitive example the instructions contained in >> British Standard 6008 (BS 6008:1980, ISO 3103:1980): "Method for >> Preparation of a liquor of tea ... ", of which a PDF copy can be >> found at >> >> http://ftp.ee.surrey.ac.uk/papers/AI/L.Gillam/bs_tea.pdf > > That looks like it might also be an interesting read. I'll take a > look at it later. Thanks. > > Regards, > Keith. As a taster (pun intended): 4 Principle Extraction of soluble substances in dried tea leaf, contained in a porcelain or earthenware pot, by means of freshly boiling water, pouring of the liquor into a white porcelain or earthenware bowl, examination of the organoleptic properties of the infused leaf, and of the liquor with or without milk or both. Best wishes, Ted. ------------ E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 01-Aug-06 Time: 12:28:38 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] explicit hyphen and numbers
On 10-Aug-06 Werner LEMBERG wrote: > > Folks, > > > Urs showed up an interesting problem in groff: A hyphen between two > numbers does *not* insert a breakpoint! To be more specific, the > .cflags values 2 and 4 of a character x are only active if the > characters before and after x both have non-zero hyphenation codes (as > set with the `hcode' request). > > Since it isn't possible to set the hcode value for numbers, things > like `200-400' are never hyphenated. To force a break you have to > insert a zero-width breakpoint: `200-\:400'. > > I'll document this properly, but I wonder whether this behaviour > should be changed. For example, I could add a new `.cflags' value to > ignore the surrounding hyphenation codes. On the other hand, until > now there has never been a complaint... > > > Werner [Though I composed a reply it does not seem to have been sent and has disappeared from my system ... here's another try!] I can't think of a context where a true hyphen between numbers could be accetably broken. I'm excluding cases where a number-range is implied, as in Items 2-7 since this should properly be represented by an en-dash (with or without padding), as in 2\(en7 2\^\(en\^7 1\(en\^8 and cases where it really means a minus sign (for similar reasons). And, in any case, where these are the meanings you don't want a break anyway. The only kind of thing I can think of where a hyphen between numbers is appropriate is like Items item2-1 item2-2 item2-3 item 3-1 item3-5 ... and again I can't imagine that a break at a hyphen would be acceptable. Wouldnt it look just awful: . item3- -1 If anyone can think of a context where a hyphen break between two numbers is OK, I'd be very interested to hear of it! And, if the exceptions are so special, then I'm sure that Werner's workround of "\:" should be acceptable, since people are not going to need it all that pften. Meanwhile, I'm comforted that groff's behavious will prevent me from getting unwanted hyphen breaks. Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 10-Aug-06 Time: 14:46:56 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] explicit hyphen and numbers
On 10-Aug-06 Steve Izma wrote: >> From: Keith Marshall <[EMAIL PROTECTED]> >> Date: Thu, 10 Aug 2006 14:28:29 +0100 >> >> I won't! If I write a numeric range, such as `200-400', >> I *don't* want a line break to occur within it. > > Well, I'll disagree. I can't find any reference to this in either > "Words into Type" or the "Chicago Guide ...", but when setting > indexes on short lines (e.g., two columns on book page, which > gives you about 10 to 12 picas, usually indented), any place > where you can get a line break is very important. By the way, > most style guides recommend using an en dash here, which is > subject to the same .hcode and .cflag issues as a hyphen. So I'm > keen on the idea of having another .cflag code to increase our > options in such situations. > > Even in the middle of a regular text block, I don't think anyone > is going to confuse a range of numbers broken at the end of a > line with a hyphenated long number, which essentially is never > needed. Yes, that does make something of a case for it, and indeed it does occur. But even so I think it can be avoided in most cases. Fr example, I just checked in the index of a book "Multivariate Analysis" (Mardia, Kent & Bibby, Academic Press 1979). In one entry I see: seemingly unrelated regressions, 203- 5, 211 and in another: simultaneous confidence intervals, 144-5 (the interword gaps in the book being relatively wider than shown in the second example). Both cases could have been improved in appearance by not filling the lines: seemingly unrelated regressions, 203-5, 211 simultaneous confidence intervals, 144-5 especially since some index entries are short lines anyway, leading to a ragged-right effect overall -- e.g. (and I've chosen a series which mixes the effects): canonical correlation analysis, 5, 281- 99 contingency table, 290-3, 299 discriminant analysis, 320, 230 prediction, 289-90 ridge technique, 298 score, 289-90 which I reckon would look better if both the range-break and the filling were turned off, giving canonical correlation analysis, 5, 281-99 contingency table, 290-3, 299 discriminant analysis, 320, 230 prediction, 289-90 ridge technique, 298 score, 289-90 What opinions do others have? Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 10-Aug-06 Time: 17:24:32 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] explicit hyphen and numbers
On 11-Aug-06 Werner LEMBERG wrote: >> > BTW, in German, AFAIK, you should use `-', not \[en]. >> >> Are you sure about this? > > No. My memory seems to fail... Are you sure? (I can't remember ever forgetting anything :) Ted. -------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 11-Aug-06 Time: 09:33:56 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] soelim and file names defined in string registers
On 18-Aug-06 Joerg van den Hoff wrote: > hi, > looking at the docs and the archives I did'nt find this: > if there are preprocessor directives in a sourced file and > the file name is specified in a string register in the > document errors result. > > say I have to files `t2' and `t3' which are to be sourced > from within this document `t1': > > == > .ds fname t3 > .so t2 > .LP > .so \*[fname] > == > > difference is that `t3' is specified in a string register. > running `soelim' on this yields in the example (t2, t3 > containing some pic stuff): > === > .lf 1 ./t1 > .ds fname t3 > .lf 1 ./t2 > sourced file's name specified as text. > .PS > boxwid = 0.5 > box > down > box > .PE > > > .lf 3 ./t1 > .LP > .so \*[fname] > = > > i.e. `t2' is already included, but the second `.so' is not yet > expanded(or what???). formatting this (or the orignal `t1') > with something like > > groff -s -ms -p -X t1 > > generates the error: > > t3:2: macro error: bad arguments to PS (not preprocessed with pic?). > > without preprocessor stuff in the sourced files, everything seems > to work (ms macros do no harm, for instance). > > could someone, please, explain what exactly the problem is > (or tell me to RTFM on page xxx...)? even better would be a > solution/work around how to specify file names of sourced files > via variables/string registers from within the document > (the -I option is not what I'm looking for) > > many thanks > > joerg Surely, Joerg, the problem is that the file t3 is not seen until the 'troff' component of the chain is started, since it is troff that executes ".so". Therefore, since the preprocessor'pic' has been run before 'troff' starts, 'pic' has not processed the contents of file t3. This would apply to any file with preprocessor material in it (e.g. 'eqn'). There is only one work-round that I know for the situation where you want to bring in a file in the middle of a troff document, where the file contains preprocessor material. This involves using ".sy" to cause the system to run the preprocessor on the file, storing its output into a temporary file, and then using ".so" to read in the contents of the temporary file. This would be on the lines of .sy pic t3 > t3.temp .so t3.temp .sy rm t2.temp So, if you already have the name "t3" defined as the string fname, the equivalent would be .sy pic \*[fname] > \*[fname].temp .so \*[fname].temp .sy rm \*[fname].temp which should work. NB You must be running groff in "unsafe" mode for this, since "safe" mode suppresses most commands (including ".sy") for something to be done by the system. Hoping this helps, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 18-Aug-06 Time: 12:36:23 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] soelim and file names defined in string registers
On 18-Aug-06 Joerg van den Hoff wrote: > [...] > Ted, > > it does, thanks a lot. I see the problem now: `soelim' (which > is the first preprocessor called anyway) silently ignores the > `.so' request including the string register and that's why the > `.so' survives until troff gets into gear after the other > preprocessors, right? The real problem there is the converse of the other problem Since 'soelim' is a pre-processor, it is run before 'troff' sees the file. So at that stage, the form of the request (as seen by 'soelim') is .so \*[fname] since troff has not yet had a chance to define the string! Since there is no file "\*[fname]" (I dare say), 'soelim' will not have anything to work with. So it is not that it "silently ignores" the request -- rather, it executes it and finds nothing there. > thanks, too, for the workaround. I will think about it > (also running "unsafe" is not always desirable ...). Not always, perhaps, but depending on your environment it may nearly always be perfectly safe! The normal dependency on pre-processers, while allowing a wide range of sophisticated work to be done, does require you to keep in mind what parts of the file have been seen, and what parts not seen, by the various components of a 'groff' pipeline, at any stage of the processing. I have sometimes (slightly mad idea ... ) considered (at least experimentally) re-writing relevant macros such as ".PS/.PE", ".TS/.TE", ".EQ/.EN" so that they automatically write out what occurs between the start and end to a file, run the appropriate "preprocessor" program on the file, and read the output back in (on the lines of the work-round I described). In this way, the "preprocessor" aspect would disappear and in effect 'troff' would process each such block of special code as if it had the resource built-in to itself (albeit in fact forking an external program to do the job). This would make much smoother the processing of "special" material which depends on events which have occured earlier in the troff run. For example, in 'pic' is is useful to know the width of a string of text before you draw a box round it. So you could write .nr twid \w' This is text in a box 'i .PS box width \n[twid] "This is text in a box" .PE but of course \n[twid] can only be set by 'troff', and this has not been done when 'pic' sees the ".PS/.PE" block. > just an idea: the problem would go away if the `.so' > request could be told (by a second argument to the request) > to rerun all necessary preprocessors on the sourced file > before inserting it (the preprocessors could be those > specified in the groff call or explicitely specified to > the `.so' reguest). Well, this particular problem might go away, but it is only one instance of a class of similar problems (see above). And you suggestion is of course on the same lines as my "mad idea" above. > would this be a good idea It could be ... ! > (apart from the someone_has_to_implement_it aspect)? ... but that looks like a bad idea :) Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 18-Aug-06 Time: 15:53:05 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
RE: [Groff] help required regarding groff/psroff
On 28-Aug-06 Himanshu Joshi wrote: > hi, myself Himanshu i have a project in whcih i need to > get the width tables from HP laserjet fontsie fonts which > are stored inside the laserjet.. > i have windows as operating system and hp 4250 laser printer > i have downloaded gsroff and psroff 3.0 was not able to > install Psroff as it contains ".Z" files :( > i was able to print glyph by giving a unicode name..but cannot > find out the way to print the advance width,characyter/glyph with the > help of groff.. > kindly help me to solve this issue.. if there is some other > way to solve this problem do let me know. > thanx > > -- > Himanshu Joshi It is not clear what your question is. Are you trying to extract the font information from the printer itself? Or do you have files on your Windows system which contain this information, and you want to extract it from these file? If the latter, what sort of files are these? If you can clarify your question, someone may be able to help you! Best wishes, Ted. ------------ E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 28-Aug-06 Time: 19:17:05 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] help required regarding groff/psroff
On 29-Aug-06 Jeff Conrad wrote:
> Himanshu,
>
>> ... i have a project in whcih i need to get the width
>> tables from HP laserjet fontsie fonts which are stored
>> inside the laserjet..
>
> I know of no way to query the printer about the metrics for
> the built-in fonts.
> [...]
Many HP laserjet models have built-in PostScript capability
("emulation"). In theory, the font metrics for built-in PS
fonts can be accessed by PostScript commands.
E.g.
charpath flattenpath pathbox
will return 4 real numbers llx lly urx ury being the coordinates
of the corners of the boundigbox of in the current
coordiante system. Since can be a single character,
you can get the BBox for each character in a font, and print
it out in a table [formatted by groff, of course!].
There are other commands, such as 'stringwidth' which returns
the movement that occurs in the currentpoint between the start
and the end of printing the string -- returning Wx and Wy as the
horizontal and vertical displacements in userspace coordinates.
However, the 'charpath' command (which appends the character path
outlines to the current path) will fail if the font outlines
are "protected". While (according to the PostScript Reference
Manual) protection is LanguageLevel-specific, I would expect
that manufacturers might be able to "protect" any fonts they
have designed themselves, for instance.
So it would be a case of "suck it and see" for any specific
model of HP laserjet printer.
And I myself have no idea about extracting the font metrics
from a non-PostScript HP printer.
Best wishes,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 29-Aug-06 Time: 13:35:32
-- XFMail --
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
[Groff] "Cosmetic" filling
Hi Folks, A little query which I perhaps ought to know the answer to ... Suppose you have the last line of a paragraph, and (formatted) it is nearly as long as the line-length. Normally, such a line which is shorter then the line-length would not be filled. But it can be aesthetically pleasing to stretch it slightly so as to really fill the line-length. 1. I'm not aware of a simple mechanism in groff to do this -- e.g. fill all lines whose minimum formatted length is within X of line-length. 2. Observation of some groff output suggests to me that groff may already do this (or maybe it was just a coincidence);[1] but if it does then I don't know how it does it nor how to control it. There is the "\p" sequence which forces a particular line to be stretched to fill, but this of course requires micro-editing by the user (what's new? :). [1] I have just written a 1-page document in which I noticed that two standalone lines, as output, and one final line of a paragraph, all seemed to exactly fill the line-length. I verified this using a duplicate of the lines terminated with "\p": at high magnification in ghostview the two ends are at exactly the same vertical position, to within ocular resolution! Any comments? ------------ E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 29-Aug-06 Time: 23:18:40 -- XFMail -- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
