> Attached is a patch containing the fix I suggested.
Applied, thanks!
Werner
Ted Harding:
> And, just for comparison, in the ms macros the variables
> (amongst others) are defined:
>
> \n[PD] "Paragraph Drop": space before the next paragraph
> \n[DD] "Display Drop": space before and after a display
>
> I prefer, myself, to set these to zero, and explicitly
> insert whateve
On 04-Feb-11 21:35:06, Larry Jones wrote:
> Anton Shepelev writes:
>> As you see, the space after the list item ending
>> with the display is twice that after the following
>> list item. The same thing happens with sections (.H)
>> and in all other instances of .DE being followed by
>> a mac
Anton Shepelev writes:
>
> As you see, the space after the list item ending
> with the display is twice that after the following
> list item. The same thing happens with sections (.H)
> and in all other instances of .DE being followed by
> a macro that generates vertical space.
>
> If thi
Hello all,
After frowning for some time at the increased verti-
cal space after static displays in MM, when they
concluded an list item or a section, I decided to
look what was going on.
The .DE macro turned out to be generating the final
vertical space by directly calling .sp, instead
On Fri, Feb 04, 2011 at 10:21:35AM -, Ted Harding wrote:
> On 04-Feb-11 09:48:42, Werner LEMBERG wrote:
> >> The left-hand boxes in the figure contain "Filename" in Roman and
> >> below it "hash.c" in Courier. While in the pic macros both have the
> >> same x offset, "hash.c" is offset further
>> So, back to Werner's .foundry, I like the idea but would like a way
>> for gropdf to take advantage of the inbuilt Adobe versions of fonts
>> when they are available.
>
> The URW fonts are intended to be used as a transparent fallback for
> the base fonts, so I think that groff should always us
Deri James wrote:
> One problem I see here is that this means that gropdf will be embedding every
> font that it uses (since it will be always using URW metrics for every font so
> can never use the internal Adobe version). Whilst this is not a bad thing from
> the point of view of fidelity of prin
> One problem I see here is that this means that gropdf will be
> embedding every font that it uses (since it will be always using URW
> metrics for every font so can never use the internal Adobe version).
Yes.
> Of course, if I did add font subsetting this objection would be a
> lot less.
Exa
On Fri, Feb 04, 2011 at 10:48:42AM +0100, Werner LEMBERG wrote:
>
> > The left-hand boxes in the figure contain "Filename" in Roman and
> > below it "hash.c" in Courier. While in the pic macros both have the
> > same x offset, "hash.c" is offset further to the right than
> > "Filename", when both
On Friday 04 Feb 2011 08:34:57 Werner LEMBERG wrote:
> Folks,
>
>
> while discussing integration of gropdf into groff with Deri, he told
> me that gropdf essentially depends on downloadable PFA fonts to be
> included in the created PDF files. This boils down to a dependency on
> the URW fonts of
Since my message below has not been sent to me by the groff
list (after 1 hour), nor has appeared in the archives, I am
re-sending it (and taking the opportunity to add a further
comment -- se at end).
-FW: -
Date: Fri, 04 Feb 2011 10:21:35 - (GMT)
From: (Ted Harding)
To: groff@gnu.o
On 04-Feb-11 09:48:42, Werner LEMBERG wrote:
>> The left-hand boxes in the figure contain "Filename" in Roman and
>> below it "hash.c" in Courier. While in the pic macros both have the
>> same x offset, "hash.c" is offset further to the right than
>> "Filename", when both were expected to be exact
> The left-hand boxes in the figure contain "Filename" in Roman and
> below it "hash.c" in Courier. While in the pic macros both have the
> same x offset, "hash.c" is offset further to the right than
> "Filename", when both were expected to be exactly left-aligned.
> Note that changing \fC to \fR
Roger Leigh wrote:
> The left-hand boxes in the figure contain "Filename" in Roman and
> below it "hash.c" in Courier. While in the pic macros both have the
> same x offset, "hash.c" is offset further to the right than "Filename",
> when both were expected to be exactly left-aligned. Note that ch
Hi,
I'm coming back to using groff after a long time, so please forgive
my ignorance if this is due to my inexperience!
I've attached below a simple ms document with an embedded pic figure.
I've also attached a ps file of the output I get using groffer.
The left-hand boxes in the figure contain
Folks,
while discussing integration of gropdf into groff with Deri, he told
me that gropdf essentially depends on downloadable PFA fonts to be
included in the created PDF files. This boils down to a dependency on
the URW fonts of GhostScript.
>From time to time people have asked whether URW fo
17 matches
Mail list logo
