Re: Happy new Sun (was: man-pages-6.02 released)

nts. Cheers Deri

Re: Happy new Sun (was: man-pages-6.02 released)

On Thursday, 22 December 2022 21:57:52 GMT G. Branden Robinson wrote: > > You can take it as a Christmas present Now, I'm officially waiting > > for groff-1.23 to be released to declare it as a dependency. Deri > > sent me a present for Christmas, and it would be a much smal

Re: groff 1.23.0.rc2 status report (was: [BUG] gropdf, tbl: Completely broken table)

happening just place ‘.pdfmarksuspend’ and ‘.pdfmarkrestart’ at the start and end of the page trap macro, respectively. (These are just convenience macros which emit the \X code. These macros must only be used within page traps.) If you look at om.tmac you will see these used in the FOOTER macro.

Re: [BUG] gropdf: Hardcoded (spaces) indentation in .EX/.EE is ignored

the same issue as with the suffixes(7) > page. Lines with leading spaces, be they in table entries as there or > not, as here, are not being handled correctly, and that could be > throwing off subsequent arithmetic involving the drawing position. Hi Alex, Exactly the same issue, premature evisceration (of leading spaces)! Fixed version in the same place. Cheers Deri

Re: [BUG] gropdf, tbl: Completely broken table (was: Ping^1: Chapters of the manual (was: Bug#1018737: ...))

likely to be an issue with code which is just a few hours old. Any faults, or changes you would like, please send to me, since it is not relevent to the groff list. Cheers Deri

Re: using the SS (slanted symbol) font with gropdf

On Tuesday, 13 December 2022 20:26:53 GMT G. Branden Robinson wrote: > Hi Deri, > > At 2022-11-27T01:41:57+0000, Deri wrote: > > I have looked at the SS font now. > > > > It is not included in devpdf because symbolsl.pfa is not a type 1 > > postscript font!

Re: words (and commands) that I learnt because of Branden (was: preferred /proc//xxx style?)

ible with your use. > > Cheers, > > Alex If deriliction was a word I think it would be unsavoury. :-) Cheers Deri

Re: Dynamic Paperlength for PS or PDF device

pt a separate print job, it should do the cutting for you. Just give groff a sufficiently long page length for the longest ticket you expect. I have a Brother thermal printer which I use for labels, but it will take a continuous role instead, and I believe it has a proprietary EscP command for controlling the cutting, so there may be a solution using something similar. Cheers Deri

Re: Doubts about a typo fix

On Saturday, 26 November 2022 21:56:04 GMT G. Branden Robinson wrote: > Deri, can you help me come up with a list of things that will break when > running ps2pdf over a PostScript document? PDFs produced that way will > have no CMap. What will happen to PS documents that use the

Re: using the SS (slanted symbol) font with gropdf

On Saturday, 26 November 2022 20:23:22 GMT G. Branden Robinson wrote: > This is probably of most interest to Deri but I thought I'd send it to > the list. > > This is kind of a follow-up to a message from July. > > https://lists.gnu.org/archive/html/groff/2022-07/msg00145.htm

Re: Doubts about a typo fix

On Saturday, 26 November 2022 03:52:53 GMT G. Branden Robinson wrote: > Some distributors do violence to the man.local file. But I am not a PDF > expert; for this I'll have to turn as I often do to Deri James, who also > wrote the gropdf output driver. Deri, what's a good way to r

Re: gropdf paper format diagnostic message and rev{i, er}sion plans (was: gropdf landscape orientation support)

On Friday, 25 November 2022 03:20:32 GMT G. Branden Robinson wrote: > Hi Deri, > > Can you bring me up to speed with what you're working on, or what you're > waiting on me to do? My recollection of last Friday was that we were > deadlocked, but that I yielded by pushing 3 reve

Re: gropdf paper format diagnostic message and rev{i, er}sion plans (was: gropdf landscape orientation support)

On Friday, 18 November 2022 17:29:46 GMT G. Branden Robinson wrote: > Hi Deri, > > I'm about to spend a good deal of my weekend out of pocket, so I might > not be able to follow up on the landscape/rotation discussion right > away. But I did want to go ahead and run something

Re: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.

On Friday, 18 November 2022 01:31:22 GMT G. Branden Robinson wrote: > Hi Deri, > > At 2022-11-17T01:22:48+0000, Deri wrote: > > On Wednesday, 16 November 2022 22:57:45 GMT G. Branden Robinson wrote: > > > I therefore propose something like: > > > > > >

Re: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.

On Friday, 18 November 2022 01:31:22 GMT G. Branden Robinson wrote: > Hi Deri, > > At 2022-11-17T01:22:48+0000, Deri wrote: > > On Wednesday, 16 November 2022 22:57:45 GMT G. Branden Robinson wrote: > > > I therefore propose something like: > > > > > >

Re: gropdf landscape orientation support (was: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.)

On Friday, 18 November 2022 00:30:28 GMT G. Branden Robinson wrote: > Hi Deri, > > At 2022-11-17T21:29:43+0000, Deri wrote: > > Hi Branden, > > > > In papersize.tmac I see this in a comment:- > > > > groff -Tps -dpaper=a4l -P-pa4 -P-l -ms foo.ms > foo

Re: gropdf landscape orientation support (was: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.)

ou examine the contents of the pdf produced you will see substantial differences even though they may look the same on the screen. You might like to think about whether -dpaper= should trigger an appropriate \X'papersize' if output is pdf, which would ensure both groff and gropdf are singing from the same hymn book. Cheers Deri

Re: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.

me, running Poppler's pdffonts(1) to scan the > generated file is extremely undesirable because doing so doubles groff's > build time on my system (and surely others'). I'm open to suggestions. What about a gropdf exit code based on whether any warnings or error messages are emitted during the run, could you then test this in the make file, setting your green or red flag. Cheers Deri > Regards, > Branden

Re: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.

me, running Poppler's pdffonts(1) to scan the > generated file is extremely undesirable because doing so doubles groff's > build time on my system (and surely others'). I'm open to suggestions. What about a gropdf exit code based on whether any warnings or error messages are emitted during the run, could you then test this in the make file, setting your green or red flag. Cheers Deri > Regards, > Branden ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit

Re: [groff] 22/40: [devpdf]: Do more explicit work and less magic.

. So in reality you will find grops without gropdf, but never t’other way round. And if you are using rm -rf as the root user you deserve to find out that things can be a bit different, you naughty boy. Cheers Deri

Re: [groff] 19/40: [devpdf]: Tweak generation of "download" file.

On Wednesday, 16 November 2022 23:09:37 GMT G. Branden Robinson wrote: > Hi Deri, > > At 2022-11-16T22:52:34+0000, Deri wrote: > > Parts of this is fine, (removing the space separators), but I did not > > quite understand the changes to devpdf.am, > > [which

Re: [groff] 19/40: [devpdf]: Tweak generation of "download" file.

On Wednesday, 16 November 2022 23:09:37 GMT G. Branden Robinson wrote: > Hi Deri, > > At 2022-11-16T22:52:34+0000, Deri wrote: > > Parts of this is fine, (removing the space separators), but I did not > > quite understand the changes to devpdf.am, > > [which

Re: [groff] 19/40: [devpdf]: Tweak generation of "download" file.

On Saturday, 12 November 2022 20:26:08 GMT Deri wrote: > On Saturday, 12 November 2022 19:43:37 GMT G. Branden Robinson wrote: > > gbranden pushed a commit to branch master > > in repository groff. > > > > commit 6838addc2924c45874e7f3f8ebaf46716c4c3613 >

Re: [groff] 19/40: [devpdf]: Tweak generation of "download" file.

On Saturday, 12 November 2022 20:26:08 GMT Deri wrote: > On Saturday, 12 November 2022 19:43:37 GMT G. Branden Robinson wrote: > > gbranden pushed a commit to branch master > > in repository groff. > > > > commit 6838addc2924c45874e7f3f8ebaf46716c4c3613 >

Re: [groff] 24/40: [build]: Refactor handling of PDF FreeEuro font.

On Saturday, 12 November 2022 20:19:04 GMT Deri wrote: > On Saturday, 12 November 2022 19:43:38 GMT G. Branden Robinson wrote: > > gbranden pushed a commit to branch master > > in repository groff. > > > > commit 83004cbf0c8e30bd700f9ef246629ab77de96a7c >

Re: [groff] 24/40: [build]: Refactor handling of PDF FreeEuro font.

On Saturday, 12 November 2022 20:19:04 GMT Deri wrote: > On Saturday, 12 November 2022 19:43:38 GMT G. Branden Robinson wrote: > > gbranden pushed a commit to branch master > > in repository groff. > > > > commit 83004cbf0c8e30bd700f9ef246629ab77de96a7c >

Re: [groff] 22/40: [devpdf]: Do more explicit work and less magic.

On Saturday, 12 November 2022 20:16:21 GMT Deri wrote: > On Saturday, 12 November 2022 19:43:38 GMT G. Branden Robinson wrote: > > gbranden pushed a commit to branch master > > in repository groff. > > > > commit 254e13c387a7fdd0267fac697737b5862c0851ad >

Re: [groff] 22/40: [devpdf]: Do more explicit work and less magic.

On Saturday, 12 November 2022 20:16:21 GMT Deri wrote: > On Saturday, 12 November 2022 19:43:38 GMT G. Branden Robinson wrote: > > gbranden pushed a commit to branch master > > in repository groff. > > > > commit 254e13c387a7fdd0267fac697737b5862c0851ad >

Re: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.

On Saturday, 12 November 2022 20:11:09 GMT Deri wrote: > On Saturday, 12 November 2022 19:43:35 GMT G. Branden Robinson wrote: > > gbranden pushed a commit to branch master > > in repository groff. > > > > commit 4753f2b17b8d836cf66fcb17f5412239e8b45743 >

Re: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.

On Saturday, 12 November 2022 20:11:09 GMT Deri wrote: > On Saturday, 12 November 2022 19:43:35 GMT G. Branden Robinson wrote: > > gbranden pushed a commit to branch master > > in repository groff. > > > > commit 4753f2b17b8d836cf66fcb17f5412239e8b45743 >

Re: Putting hyperlinks in a PDF document

On Tuesday, 15 November 2022 19:21:05 GMT G. Branden Robinson wrote: > At 2022-11-15T18:35:35+0000, Deri wrote: > > Incidentally using \X'papersize ..." you can mix portrait and > > landscape in the same document. > > It's a shame that gropdf(1) is the only out

Re: Putting hyperlinks in a PDF document

On Tuesday, 15 November 2022 14:37:20 GMT G. Branden Robinson wrote: > [adding Peter for a mom question] > > Hi Deri, > > At 2022-11-15T13:43:49+, Deri wrote: > > It's a bug, try this work-around:- > > > > groff -Tpdf -mm -dpaper=letterl

Re: Putting hyperlinks in a PDF document

changes the document from portrait to landscape as expected. But > the hyperlink code no longer works. > > Thanks! > > Blake Hi Blake, It's a bug, try this work-around:- groff -Tpdf -mm -dpaper=letterl -rW=9i hyperlink.mm -P-p8.5i,11i > hyperlink.pdf Cheers Deri

Re: [groff] 19/40: [devpdf]: Tweak generation of "download" file.

On Saturday, 12 November 2022 19:43:37 GMT G. Branden Robinson wrote: > gbranden pushed a commit to branch master > in repository groff. > > commit 6838addc2924c45874e7f3f8ebaf46716c4c3613 > Author: G. Branden Robinson > AuthorDate: Wed Nov 9 08:24:52 2022 -0600 > > [devpdf]: Tweak

Re: [groff] 19/40: [devpdf]: Tweak generation of "download" file.

On Saturday, 12 November 2022 19:43:37 GMT G. Branden Robinson wrote: > gbranden pushed a commit to branch master > in repository groff. > > commit 6838addc2924c45874e7f3f8ebaf46716c4c3613 > Author: G. Branden Robinson > AuthorDate: Wed Nov 9 08:24:52 2022 -0600 > > [devpdf]: Tweak

Re: [groff] 24/40: [build]: Refactor handling of PDF FreeEuro font.

ot;, "NR", "PB", "PBI", "PI", "PR", "S", "TB", "TBI", > +"TI", "TR", "ZCMI", "ZD", > +); > + > if ($check) > { > CheckFoundry("Foundry.in"); > @@ -11

Re: [groff] 24/40: [build]: Refactor handling of PDF FreeEuro font.

ot;, "NR", "PB", "PBI", "PI", "PR", "S", "TB", "TBI", > +"TI", "TR", "ZCMI", "ZD", > +); > + > if ($check) > { > CheckFoundry("Foundry.in"); > @@ -115,7 +124,7 @@ sub LoadFoundry > > my $gfont=($foundry eq '')?$r[0]:"$foundry-$r[0]"; > > - if ($r[2] eq '') > + if ($r[2] eq '' && grep /^$r[0]$/, @base35Fonts) > { > # Don't run afmtodit; just copy the groff font > # description file for grops. > @@ -142,7 +151,6 @@ sub LoadFoundry > } > } > Notice("copied grops font $gfont") if $gotf; > - > } > else > { > > ___ > Groff-commit mailing list > groff-com...@gnu.org > https://lists.gnu.org/mailman/listinfo/groff-commit And this one. Cheers Deri

Re: [groff] 22/40: [devpdf]: Do more explicit work and less magic.

freeeuro.afm font/devpdf/map/symbol.map \ > + EURO > + > +MOSTLYCLEANFILES += font/devpdf/freeeuro.pfa > +font/devpdf/freeeuro.pfa: $(devps_srcdir)/freeeuro.pfa > + $(AM_V_GEN)$(MKDIR_P) $(top_builddir)/font/devpdf \ > + && cp -f $(devps_srcdir)/freeeuro.pfa $@ > + > font/devpdf/Foundry: $(devpdf_srcdir)/Foundry.in > $(AM_V_at)$(MKDIR_P) $(top_builddir)/font/devpdf/ > if HAVE_URW_FONTS > > ___ > Groff-commit mailing list > groff-com...@gnu.org > https://lists.gnu.org/mailman/listinfo/groff-commit And this one please. Cheers Deri

Re: [groff] 22/40: [devpdf]: Do more explicit work and less magic.

freeeuro.afm font/devpdf/map/symbol.map \ > + EURO > + > +MOSTLYCLEANFILES += font/devpdf/freeeuro.pfa > +font/devpdf/freeeuro.pfa: $(devps_srcdir)/freeeuro.pfa > + $(AM_V_GEN)$(MKDIR_P) $(top_builddir)/font/devpdf \ > + && cp -f $(devps_srcdir)/freeeuro.pfa $@ > + > font/devpdf/Foundry: $(devpdf_srcdir)/Foundry.in > $(AM_V_at)$(MKDIR_P) $(top_builddir)/font/devpdf/ > if HAVE_URW_FONTS > > ___ > Groff-commit mailing list > Groff-commit@gnu.org > https://lists.gnu.org/mailman/listinfo/groff-commit And this one please. Cheers Deri ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit

Re: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.

eferences; and move parenthesized groff font name > + outside of single quotes. > + (LoadFont): Recast diagnostic message to communicate the > + foregoing information. Also make embedding failure messages > + more consistent in style. > + > 2022-11-08 Deri James

Re: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.

eferences; and move parenthesized groff font name > + outside of single quotes. > + (LoadFont): Recast diagnostic message to communicate the > + foregoing information. Also make embedding failure messages > + more consistent in style. > + > 2022-11-08 Deri James

Re: build, BuildFoundries, and gropdf changes coming

tory. > > (font/devpdf/freeeuro.pfa): Add new target, a simple file copy from > the devps font directory. > > (MOSTLYCLEANFILES): Clean freeeuro.{afm,pfa}. Why duplicate freeeuro.{afm,pfa} from devps? > Regards, > Branden > > [1] > https://git.savannah.gnu.org/cgit/groff.git/commit/?id=7e5d433ba5ddc2389986 > a5c02f91eb57fc1de47d > > [2] The FreeEuro font file is cheekily located at > "../devps/freeeuro.pfa", which is nicely robust for a groff _build_ > but pretty dubious for installation. I don't understand this. Why is it cheeky, looks like a normal relative path to me? Why is it dubious for installation? You may have missed that gropdf converts all relative paths to an absolute path while reading download files. Cheers Deri

Re: Nimbus fonts missing (was: [BUG] man(7) page not showing footer)

On Tuesday, 8 November 2022 20:07:02 GMT Alejandro Colomar wrote: > > Deri, do you have the changes you mentioned in > > https://savannah.gnu.org/bugs/?62950#comment5 ready to push? > > I saw his email about being locked out Hi Alejandro, I have now pushed changes to grop

[bug #62950] [gropdf] revise 'download' resolution process

Update of bug #62950 (project groff): Item Group: Feature change => Build/Installation Open/Closed:Open => Closed ___ Reply to this item at:

[bug #62950] [gropdf] revise 'download' resolution process

Update of bug #62950 (project groff): Status: In Progress => Fixed ___ Follow-up Comment #9: I have pushed the changes. Will close as the freeeuro thing is not something I can fix in gropdf.

[groff] 01/01: [gropdf]: Cater for invalid entries in download file.

deri pushed a commit to branch master in repository groff. commit 7e5d433ba5ddc2389986a5c02f91eb57fc1de47d Author: Deri James AuthorDate: Tue Nov 8 21:03:49 2022 + [gropdf]: Cater for invalid entries in download file. * src/devices/gropdf/gropdf.pl: Test if path in the download

[bug #62950] [gropdf] revise 'download' resolution process

Follow-up Comment #7, bug #62950 (project groff): I have finished testing and found an issue, not really related to this issue but found during testing. Since the groff_man_pages.pdf uses the freeeuro font the download file in build/font/devpdf correctly has the entry "../devps/freeeuro.pfa"

Re: [BUG] man(7) page not showing footer

system directory, and gropdf choosing the last matching path. which will become moot when the changes below are applied. > Deri, do you have the changes you mentioned in > https://savannah.gnu.org/bugs/?62950#comment5 ready to push? Unfortunately I have been locked out of my garden office for sever

[bug #63179] sqrtex and radicalex are really weird glyphs, man

Follow-up Comment #4, bug #63179 (project groff): What info is required for this "feature"? You can see more discussion in this thread https://lists.gnu.org/archive/html/bug-groff/2022-11/msg8.html ___ Reply to this item at:

[bug #62950] [gropdf] revise 'download' resolution process

Follow-up Comment #5, bug #62950 (project groff): I am still testing, but the coding is done. I am still lazy, but we can live in hope! As regards grops the simplest implementation would be to change my two hashes into two arrays of fontname fontpath structures (as it probably does now), for

Re: \[sqrtex] woes (related to bugs bug #62923 and #63179)

font. Whether afmtodit can be amended to handle this I am not sure. It would be helpful if you could check if one of your fonts which has a sqrt glyph but no radicalex actual contains a glyph for U0305, and if so, does it "fit" with the sqrt. Cheers Deri > thx, > joerg

Re: \[sqrtex] woes (related to bugs bug #62923 and #63179)

demo (I reiterate: all font-internal > definition of sqrt and radicalex are removed from the external font > definition files): I'm afraid the sqrt2.pdf is not helpful because it has not been produced by groff, please can you do the same as your original sqrt.pdf (without the .rchar) using your patched fonts with sqrt removed. Cheers Deri

[bug #62950] [gropdf] revise 'download' resolution process

Follow-up Comment #2, bug #62950 (project groff): I think this is a bit more than a wish. The current gropdf behaviour (choose last) causes build to fail if site or system download file contains "stale" entries for the groff system fonts. Staleness can occur if ghostscript is updated without

Re: \[sqrtex] woes (related to bugs bug #62923 and #63179)

he glyph do not do that but > properly extent the bar. or so it seems. Also, in ps.tmac, \[sqrtex] is made a synonym for \[radicalex], which is why groff is using \[radicalex] from the Garamond font. The .rchar command above should fix the problem of the misplaced over line. The other fonts which d

Re: \[sqrtex] woes (related to bugs bug #62923 and #63179)

ther than what follows), so they don't need the same correction. What happens if you include the command .rchar radicalex to remove this correction? Cheers Deri

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #20, bug #62860 (project groff): Branden did ask for ./font/devpdf/download I did not realise you gave him this file instead. The dot was meant to refer to the directory in which you did the "make" rather than /usr/share/local/groff/site_font/devpdf. Also I missed out one

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #18, bug #62860 (project groff): Please could you attach the file /usr/local/share/groff/site-fonts/download. ___ Reply to this item at:

Re: mom and custom page sizes

ime env clear hostnamectl ps exit, > agetty login adduser dd bzip shutdown. > > $ pdfmom example.mom > example-custom-15x15.pdf If you set DOCTYPE SLIDES you will find the pdf is the correct size, but you lose the author/title section. The reason is because in the macro DEFAULTS which is called from START sets the papersize for gropdf to LETTER, or the value set by .PAPER, for any DOCTYPE except SLIDES. Cheers Deri

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #14, bug #62860 (project groff): What we know:- The filepaths in the built download file are correct. So gropdf must be reading a different download. The locations to search for the download file are hard-coded in line 59. After the path in GROFF_FONTPATH it looks in site-font.

[bug #63179] sqrtex and radicalex are really weird glyphs, man

Follow-up Comment #2, bug #63179 (project groff): You should not be so surprised!! If you have a look at the file s.pdf attached to bug #62923, and my long comments in that bug you will see that I demonstrated the same thing. The equivalent glyph in font XITSMR does not behave this way, it is

Re: wrong URW font directory used by gropdf (was: installed 'gropdf' incorrectly used for compilation)

generic > fonts but all the way at the end of the search path for fonts using the > 'U' (URW) foundry. > > Deri may well have explained this to me before and I have forgotten. If > the distinct placement is deliberate, we should add an explanatory > comment. Hi Branden, So, there

[bug #62923] [gropdf] glyph aliases in font description files not parsed correctly

Follow-up Comment #17, bug #62923 (project groff): Whilst you are correct the original submission matched the title, this was fixed in comment #1.All further comments then onwards are an entirely different issue which affects grops as well as gropdf. It seems odd to have an open ticket asigned to

[bug #62923] [gropdf] glyph aliases in font description files not parsed correctly

Update of bug #62923 (project groff): Category: Device gropdf => Preprocessor eqn ___ Reply to this item at: ___

[bug #63074] [troff] need a way to embed non-Basic Latin glyphs in device control commands

Follow-up Comment #11, bug #63074 (project groff): The messages which started this bug: "special characters are not defined", have very little to do with the message you recently suppressed. This message is because groff starts up with the TR font, which has no Cyrillic glyphs, and if the macro

[bug #62996] [gropdf] mom-pdf: type size weirdness in text

Follow-up Comment #2, bug #62996 (project groff): This may help (using 1.22.4 which also has the problem). It is the -Z output with just the text (t) and size (s) commands:- s10500 tIf tgr toff ts tP tostScr tipt tde tvice t( tTps t) tis tused ... tthe tT tOC tis s10440 t.AUTO_RELOCATE_TOC t[]

[bug #62955] [grops] \(va fallback character overrides glyph available in S font

Follow-up Comment #2, bug #62955 (project groff): Nikita uses XITSMath-Regular.pfa as his "special" font so if you try:- .special XITSMR .rchar \[va] .ps 36 .vs 42 .nf \(rsva: \(va \(rso\(aq\(rsua\(rsda\(aq: \o'\(ua\(da' You will see the raw \[va] used from the font is slightly superior to

[bug #62923] [gropdf] glyph aliases in in font description files not parsed correctly

Follow-up Comment #14, bug #62923 (project groff): I also found this on wikipedia https://en.wikipedia.org/wiki/Symbol_(typeface) The character at 0x60 does not appear in Unicode. It is described in the Adobe map as "RADICAL EXTENDER", with the Adobe glyph name "radicalex", and is mapped to the

[bug #62923] [gropdf] glyph aliases in in font description files not parsed correctly

Follow-up Comment #13, bug #62923 (project groff): Yes, that's what I meant, \[sqrtex] is hard coded. :-) When you install XITSMR repeat your test with .special XITSMR, then you can see the problem. With .special S everything looks normal. In XITSMR sr is an alias for sqrt and radicalex is an

[bug #62934] [gropdf] sometimes \(em becomes a different char when rendered

Follow-up Comment #10, bug #62934 (project groff): That one is also after a vim modeline was added to the bottom of gropdf in git. I will add it to my working copy so they are the same, maybe that will settle it down. ___ Reply to this

[bug #62923] [gropdf] glyph aliases in in font description files not parsed correctly

Update of bug #62923 (project groff): Assigned to:deri => None ___ Follow-up Comment #10: I'm not sure what extra information you require, I fixed and closed the original bug, confir

[bug #62934] [gropdf] sometimes \(em becomes a different char when rendered

Update of bug #62934 (project groff): Planned Release: 1.23.0 => 1.20.0 ___ Follow-up Comment #7: Thanks for this good advice, but does not explain why it has started happening.

[bug #62934] [gropdf] sometimes \(em becomes a different char when rendered

Follow-up Comment #5, bug #62934 (project groff): I'm not sure what happened, both of my last commits were one liners where I used kompare to change the single line which was relevent from my working copy of gropdf. This is the workflow which I have always used:- git stash git pull Run kompare

Re: [bug #62941] groff no longer warns about nonexistent font

On Tuesday, 23 August 2022 03:36:29 BST Dave wrote: > * I discovered this when poking into bug #62934 (which I was ultimately > unable to reproduce because I lacked the needed font). Nikita used a font called TMR, could not reproduce with TinosR but found U-TR did show the bug. Cheers Deri

[groff] 01/01: Bug #62934 - after glyph remapped mark it as used

deri pushed a commit to branch master in repository groff. commit f275b477e0f49d180224a77271c1b68e913b71b5 Author: Deri James AuthorDate: Mon Aug 22 23:30:40 2022 +0100 Bug #62934 - after glyph remapped mark it as used When many glyphs are remapped from code points above 255

Re: Font path issue

On Sunday, 21 August 2022 17:26:55 BST G. Branden Robinson wrote: > Hi Deri, > > At 2022-08-21T01:12:07+0100, Deri wrote: > > Gropdf is different, it takes into account all download files found, > > so there is no need to duplicate entries into the site-font download > &g

[bug #62934] gropdf: sometimes \(em becomes a different char when rendered with gropdf

Update of bug #62934 (project groff): Status: Need Info => Ready For Test ___ Reply to this item at: ___

[bug #62934] gropdf: sometimes \(em becomes a different char when rendered with gropdf

Update of bug #62934 (project groff): Status:None => Need Info ___ Follow-up Comment #1: This is a remapping issue. If glyphs have a code point above 255 they have to be remapped to a

[bug #62933] [man] produce hyperlinks in PDF output

Additional Item Attachment, bug #62933 (project groff): File name: groff-man-pages.pdfSize:1714 KB ___ Reply to this item at:

[bug #62933] [man] produce hyperlinks in PDF output

Follow-up Comment #1, bug #62933 (project groff): .MR only makes sense in pdf output when dealing with a man page collection in a single volume, a-la Branden's new groff-man-pages. The reason is because the link to a separate man page requires a protocol handler which fires of a call to mandb to

Re: Font path issue

On Sunday, 21 August 2022 15:17:01 BST Robert Goulding wrote: > If Deri says it looks for *all* the download files, then that must be > correct! But is the manpage out of date then? > > Robert. Hi Robert, I have corrected it on git. Cheers

Re: Font path issue

opying those entries to site-font download fixed his problem. Gropdf is different, it takes into account all download files found, so there is no need to duplicate entries into the site-font download file. You could organise your fonts into separate families, each with its own separate download file just for that family, and then list the directories separated by a ":" in GROFF_FONT_PATH. Cheers Deri

[bug #62923] [gropdf] glyph aliases in in font description files not parsed correctly

Follow-up Comment #7, bug #62923 (project groff): This probably deserves its own bug number, since the original problem is now fixed. This second reported issue is not specific to PDF output, the same problem exists with postscript, which is indicative the issue is other than the output driver,

Re: pdfmom -Tps not working

On Saturday, 20 August 2022 02:06:10 BST Peter Schaffter wrote: > Deri -- > > 'pdfmom -Tps' seems to be broken. I never use the -Tps option > so I haven't notice before. When I run > > pdfmom -Tps -ke test > test.ps > > pdfmom exits cleanly but the .ps file

[groff] 01/01: Bug #62923 - problem using aliased glyphs

deri pushed a commit to branch master in repository groff. commit 26523d0bb2d2c0cca6b3b0759888069d6846fb1f Author: Deri James AuthorDate: Sat Aug 20 01:29:12 2022 +0100 Bug #62923 - problem using aliased glyphs With a large font if 2 characters above the 255 code point limit

[bug #62923] Broken aliases in PDF font description file

Update of bug #62923 (project groff): Status:None => Fixed Assigned to:None => deri ___ Follow-up Comment #1:

[bug #62918] Wrong GhostScript version reported during build

Follow-up Comment #3, bug #62918 (project groff): > > I will be adding a new program, pdfmake, > > Please don't. > > Adding yet another program for each afterthought forgotten in the original UI > design ruins an API by adding more and more complexity and accumulating more > and more

[bug #62918] Wrong GhostScript version reported during build

Update of bug #62918 (project groff): Status:None => Need Info ___ Follow-up Comment #1: This may be an instance of what Werner reported to the list:-

Re: Updated install-font.sh

On Thursday, 18 August 2022 03:00:21 BST Peter Schaffter wrote: > Deri -- > > > I don't think the site_font download file for devpdf requires the > > Euro stuff repeated, so long as it is in the system download file > > already. Gropdf already searches in all e

[groff] 01/01: [gropdf]: Improve parsing of troff font files.

deri pushed a commit to branch master in repository groff. commit 0a4c256f3bce926e3d0829bf95447dd60b5fb5d7 Author: Deri James AuthorDate: Thu Aug 18 14:38:05 2022 +0100 [gropdf]: Improve parsing of troff font files. * src/devices/gropdf/gropdf.pl: Allow the glyph code number

Re: Updated install-font.sh

unnecessary to duplicate download entries. So far I have not heard anything. Cheers Deri

Re: One Page Dungeon Layout in groff?

dfinfo command in January. Cheers Deri

Re: One Page Dungeon Layout in groff?

ity of the convert map somewhat lacking > in the pdf example, though. I'll probably stick to what I've got. Does the map have to be a png? If it can be produced in a vector format, i.e. svg, postscript, or even built using groff draw primitives, it will considerably improve the quality of the map and substantially reduce the size of the pdf produced. Cheers Deri

Re: Greek letters not slanted in -Tps eqn output

embedded Symbolsl.pfa. If grops did include the 35 internalnames in its source then it could determine a resource was missing, by checking the internalname against that list, if it is not there and it is not found in the download file, it will know there is a problem. [snip] > > Yes, up

Re: Greek letters not slanted in -Tps eqn output

embedded Symbolsl.pfa. If grops did include the 35 internalnames in its source then it could determine a resource was missing, by checking the internalname against that list, if it is not there and it is not found in the download file, it will know there is a problem. [snip] > > Yes, up

[groff] 01/01: [man]: Correct information for gropdf.

deri pushed a commit to branch master in repository groff. commit 5b357550d90f59f4d37ae9f2ce3a562d97b78a01 Author: Deri James AuthorDate: Tue Aug 9 19:11:49 2022 +0100 [man]: Correct information for gropdf. * src/devices/gropdf/gropdf.1.man: gropdf reads multiple download files

Re: Greek letters not slanted in -Tps eqn output

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 find SS (in my previous broken > setup with disjunct `download' instances in system and my addit

Re: Greek letters not slanted in -Tps eqn output

o didact mode on the groff_out intricasies but the reason your equation was squiff is not to do with groff, its because ghostscript had no Symbol-Slanted font, picked Symbol instead and used its metrics which do not match. Cheers Deri > just wondering. no longer really relevant since problem solved :). > > best, > joerg

Re: Greek letters not slanted in -Tps eqn output

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 `download' file i

Re: Greek letters not slanted in -Tps eqn output

source: font Times-Roman %%IncludeResource: font Symbol-Slanted %%IncludeResource: font Symbol Whereas when I run with -Tps it has:- %%IncludeResource: font Symbol %%IncludeResource: font Times-Roman %%BeginResource: font Symbol-Slanted %!PS-Adobe-3.0 Resource-Font (followed by the contents of symbolsl.pfa). Cheers Deri

Re: TAB character in groff output

ar device. The euro comes from the ninth glyph in the TR font, so it depends on the particular font encoding. The glyph numbering is specified in the file text.enc, so you can have your own glyph order if desired. So not really an oops, just not what you might have expected. Cheers Deri > I expect we are soon going to dissuade Alejandro from his plan. :) > > Yours, > Ingo

<    1   2   3   4   5   6   7   8   >