hello,
currently coming back to groff more seriously after quite a long time (so having got somewhat
"rusty"), I have stumbled today over the following (observed with version 1.22.4 and ms macros):
I tried to use the `eqn' `gfont' command for switching the font used in equations to something
On 30.06.22 18:35, G. Branden Robinson wrote:
Hi Joerg,
hi brenden,
At 2022-06-29T19:45:41+0200, joerg van den hoff wrote:
hello,
currently coming back to groff more seriously after quite a long time
(so having got somewhat "rusty"), I have stumbled today over the
following
not sure whether this qualifies as a bug or is "known behaviour":
my groff installation uses A4 paper size per default (and the DESC file of
grops indeed says so much).
using the ms macros, I noted that when setting the page size to A4 in groff as
well (either manually
or via including a4.tmac
---
maybe something like this could/should be added to the eqn.1 manpage (if it _is_ the correct
solution to the problem ;)).
thank you,
joerg
On 30.06.22 19:25, joerg van den hoff wrote:
On 30.06.22 18:35, G. Branden Robinson wrote:
Hi Joerg,
hi brenden,
At 2022
On 19.07.22 16:27, Bjarni Ingi Gislason wrote:>Your observation is right.
>
>This is how groff is designed to do.
>
>The x-axis for input is on the first usable line for the output medium
> and that is one text baseline below the upper border of the physical
> output medium (paper, scr
mmh, second try: I've send the below report 8h ago but it seems to not have made it through: there
are now several more recent messages in the archive. hopefully it succeeds this time:
==original message===
I have compiled an old (>10 years) equation heavy troff ms-document and do see now issu
d before S according to DESC and this leads to rather massive typesetting
errors in equations using possibly many greek letters: cumulative mispositioning of stuff later on
the same line.
what do to about this?
thank you
joerg
On 25.07.22 22:42, joerg van den hoff wrote:
mmh, second try: I&#
On 26.07.22 18:19, Deri wrote:
On Tuesday, 26 July 2022 09:00:25 BST joerg van den hoff wrote:
me again with an update/correction to the previous description of the issue
(the described problem remains, though):
1.
regarding the symobl fonts used by grops and gropdf I previously stated the
currently considering to slowly migrate to gropdf as my default output device
(from grops + ps2pdf)
and gave PDFPIC a first try. bad luck so far ... consider this `ms' document in
a file named `tt.trf':
.LP
foo
.PDFPIC aitail.pdf
.LP
bar
.PDFPIC fig2.pdf
(both pdf files are PDF 1.4)
I see two
does only generate empty output files (both,
with grops as well as gropdf) :(
am I missing something?
br/joerg
On 31.07.22 17:47, Deri wrote:
On Sunday, 31 July 2022 10:28:50 BST joerg van den hoff wrote:
currently considering to slowly migrate to gropdf as my default output
device (from
On 31.07.22 18:57, Deri wrote:
On Sunday, 31 July 2022 17:34:19 BST joerg van den hoff wrote:
hi deri,
thank you for looking into this!
question: the pdfpic.tmac you've send is supposed to work if I include it at
top of my document (e.g. the fragment tt.trf) so that it overrules the
p
thanks for the explanations re PDFPIC and status of 1.22.4.
regarding the current issue I unintentionally replied only to deri directly in
last mail.
here is the essential part again:
I had located that sed "creature" and it indeed does not work for me. I suspect this has to do with
those ca
ok, I did what you've proposed. *none* of the commands in that pipe fails. even
the complete pipe
including `sed` yields exist status 0 but outputs
Page size: 510 x 318 pts
i.e. the unmodified output from the initial grep. this is on OSX rather than
linux.
as already stated in previous
On 07.08.22 14:52, Robert Goulding wrote:
Using groff 1.23.0.rc1.2754-d5862
Greek letters are not slanted in equations in Postscript output, but they
are in -Tpdf output. Simple example attached.
This is perhaps connected with recent activity about the SS font?
Robert.
it seems the same
hi deri,
turns out I actually _have_ had the same problem (sort of, at least): I recently installed
additional fonts and like robert was not aware that it is necessary to merge the default `download'
file into the new one.
question 1: this is really a bit cumbersome (and prone to cause problem
hi deri,
turns out I actually _have_ had the same problem (sort of, at least): I recently installed
additional fonts and like robert was not aware that it is necessary to merge the default `download'
file into the new one.
question 1: this is really a bit cumbersome (and prone to cause problem
On 08.08.22 18:49, Deri wrote:
On Monday, 8 August 2022 15:49:43 BST joerg van den hoff wrote:
hi deri,
turns out I actually _have_ had the same problem (sort of, at least): I
recently installed additional fonts and like robert was not aware that it
is necessary to merge the default
Robinson wrote:
[looping in main groff list since I went into didact mode]
Hi Joerg,
At 2022-08-08T21:32:24+0200, joerg van den hoff wrote:
I think I nearly get it now regarding font selection. but regarding
font metrics: my rudimentary understanding was/is that each glyph
essentially gets assigned a
below"
but be this at it may. the problem is artificial in so far as it onl occurs
with misconfigured
`download' in my additional fonts tree. so maybe not worth to go on about it
too long ;).
best,
joerg
On 09.08.22 00:11, Deri wrote:
On Monday, 8 August 2022 20:32:24 BST joerg v
not my day... again forgot to include the list in the address field. so second
try again:
On 09.08.22 17:05, Deri wrote:
On Tuesday, 9 August 2022 13:46:43 BST joerg van den hoff wrote:
hi deri,
thank you, although I am starting to feel obtuse :).
so what you say is *only* grops does not
On 09.08.22 20:03, Deri wrote:
On Tuesday, 9 August 2022 18:13:10 BST joerg van den hoff wrote:
question: is there a deeper reason, why grops does not traverse all known
font locations/dirs and scan all found `download' files until, hopefully, a
hit is found? I mean except "som
On 10.08.22 01:55, Deri wrote:
ok, in this case, yes. I would have expected the relative movement
being relative to the fraction bar itself, but that's obviously not
what eqn does.
This part I cannot speak to, as I have only barely begun coping with GNU
eqn's source code. If someone else kno
On 09.08.22 21:38, G. Branden Robinson wrote:
[looping in groff@ again due to a shift in discussion focus to
development]
At 2022-08-09T19:14:25+0200, joerg van den hoff wrote:
On 09.08.22 17:05, Deri wrote:
groff and grops can find the SS file, which gives the widths of the
SS glyphs, but
On 21.08.22 06:46, G. Branden Robinson wrote:
Follow-up Comment #5, bug #62921 (project groff):
[comment #4 comment #4:]
hi branden (and "person X" ;)),
chiming in again if I may.
Hi, original submitter here. Yes, your solution would be fine, but I'm a bit
confused. For groff 1.22.4 i
hi everybody,
I am also encountering the misalignment issues discussed in the above mentioned bug reports with
assorted third party fonts (using groff 1.22.4).
as far as I have understood the discussions in those threads, the problem seems
to have been
attributed to a naming collision (or rat
On 02.11.22 17:23, Deri wrote:
On Wednesday, 2 November 2022 13:08:45 GMT joerg van den hoff wrote:
as far as I have understood the discussions in those threads, the problem
seems to have been attributed to a naming collision (or rather the presence
of a sqrtex glyph in the font)?
I
respective of selected font?
thx,
joerg
On 02.11.22 17:23, Deri wrote:
On Wednesday, 2 November 2022 13:08:45 GMT joerg van den hoff wrote:
as far as I have understood the discussions in those threads, the problem
seems to have been attributed to a naming collision (or rather the presence
of a sq
On 03.11.22 18:08, Deri wrote:
On Thursday, 3 November 2022 13:32:46 GMT joerg van den hoff wrote:
Command should be:-
.rchar \[radicalx]
sorry. My expectation is that any font which does not contain
sqrtex/radicalex itself which then uses the glyph from Symbol font, will
have a space after
as a follow up to previous mail:
without understanding the full details, I know see that the DMI font definition (for
DejavuSansMono-Oblique as the orignal font name is (rather than *-italic as previously claimed ;))
not only
contains
\[sqrt]
but also a line reading verbatim:
\[sr] "
and
On 04.11.22 01:00, Deri wrote:
On Thursday, 3 November 2022 20:47:33 GMT joerg van den hoff wrote:
as a follow up to previous mail:
without understanding the full details, I know see that the DMI font
definition (for DejavuSansMono-Oblique as the orignal font name is (rather
than *-italic as
sonally believe the same is true for the .IX
removal ;)).
best,
joerg
On 04.10.24 15:10, joerg van den hoff wrote:
correction regarding the "long entries that do line break do not honour indent": this probably is
technically not a bug since in the original context the entries do hav
On 13.10.24 11:24, G. Branden Robinson wrote:
Hi Joerg,
hi branden,
it seems it would probably be best to just agree to disagree and move on, but
...
At 2024-10-13T11:03:52+0200, joerg van den hoff wrote:
but I really believe the line should never have been deleted in the
first place
On 13.10.24 15:31, G. Branden Robinson wrote:
[replying only to the lists since you're clearly subscribed, or
otherwise following them]
Hi Joerg,
hi branden,
At 2024-10-13T12:36:23+0200, joerg van den hoff wrote:
On 13.10.24 11:24, G. Branden Robinson wrote:
it seems it would pro
3T23:06:18+0200, joerg van den hoff wrote:
table of content when using ms macros (wide entries failing to line
break and "pushing" the page number out of line to the right instead).
I cannot say, however, whether this is a 1.23-related issue or whether
it just has escaped my attention pr
On 03.10.24 23:21, G. Branden Robinson wrote:
At 2024-10-03T23:06:18+0200, joerg van den hoff wrote:
table of content when using ms macros (wide entries failing to line
break and "pushing" the page number out of line to the right instead).
I cannot say, however, whether this is a 1.
I ran into this problem several months ago but did never suspect it would be related to a preceding
update to 1.23 (which happened as part of general package update run so I did not even take note
until recently that groff on my machine is actually now at 1.23) so this report comes a bit late.
On 16.10.24 19:38, G. Branden Robinson wrote:
[CCing groff@gnu and directing Reply-To there]
Hi Joerg,
hi branden,
At 2024-10-16T13:30:23+0200, joerg van den hoff wrote:
I ran into this problem several months ago but did never suspect it
would be related to a preceding update to 1.23
joerg van den hoff wrote:
At 2024-10-16T13:30:23+0200, joerg van den hoff wrote:
I ran into this problem several months ago but did never suspect
it would be related to a preceding update to 1.23 (which happened
as part of general package update run so I did not even take note
until recently tha
On 03.10.24 21:58, Deri wrote:
On Wednesday, 2 October 2024 19:29:26 BST G. Branden Robinson wrote:
To accept such a restriction is to surrender groff to stagnation. While
I am aware of at least one person for whom that situation is a
preference, I claim that the same can be achieved by neve
I was not aware of this change (not following groff development closely) and it took me quite a bit
of time today to find the root course of why some newly compiled old documents of mine do not
contain an index any more.
the reasoning in the release notes "This undocumented 4.2BSD ms extension
40 matches
Mail list logo
