Re: [Groff] mapping of glyphs to Unicode
> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes: Bruno> U+27E8..27E9 are MATHEMATICAL LEFT/RIGHT ANGLE BRACKET and Bruno> were introduced in Unicode 3.2. The glyphs are very similar Bruno> (see http://www.unicode.org/charts/symbols.html under Bruno> "Misc. Math Symbols A" and "Miscellaneous Technical"). Why Bruno> prefer one over the other? FWIW, those two glyphs are from the Symbol font. devutf8 probably uses them because the ps device uses Symbol to display la and ra. Ideally groff should use them for math and the other angle brackets for text. Differentiating intent, though, is not so easy But math vs text is the reason they are not unified in unicode. -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] mapping of glyphs to Unicode
> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes: Bruno> Can you explain more? Symbol fonts have only one 'angleleft' and only one Bruno> 'angleright' glyph. Therefore for the 'devps' device it is irrelevant Bruno> which Unicode code points we use - \(la must map to 'angleleft' and Bruno> \(ra must map to 'angleright'. So for the 'devps' device the Unicode Bruno> code points are groff internal. My point was that given that la and ra point to glyphs from the Symbol font in devps, that devutf8’s author probably presumed they should then map to the iso10646 code points which were added for compatability with the Synbol font, rather than the similar text characters. One can see how one may presume that anything coming from Symbol was intended for a math context Bruno> IMO what we do in the devutf8 and devhtml devices should not be Bruno> influenced by Adobe glyph list considerations. Agreed. I was describing my presumtion of the author's thinking, and of the unicode/10646 thinking. Part of the problem of course is that unicode/10646 deals with characters and the dev filesets were at least originally designed to deal with glyphs. That devutf8 and devhtml should map to characters rather than glyphs is true. How easy that will be in the general case — where unification vs. disunification, nfc vs nfd, et al all come into play — makes for Interesting Times. -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: groff special PS fonts
> "Werner" == Werner LEMBERG <[EMAIL PROTECTED]> writes: Werner> I assume that some `local' UniqueID is appropriate. These days Adobe recommends not using UniqueID in fonts. There are very few printers left in service that can actually benefit if each font has an UniqueID. It would be best to drop them from the fonts groff ships. (It'll take me some effort to seach for a cite if requested, but it was most likely either on opentype-list or available on their nntp server and web forum at adobeforums.com.) -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: the Courier font family and nroff history
>>>>> "GB" == G Branden Robinson writes: GR> I don't think Adobe standardized it GR> for PostScript (and then PDF) for the _sole_ purpose of simulating GR> terminal emulator, or even typewriter, output. As I recall, it has frequently been posted over the years that the selection of fonts which were included on Apple's laserwriter were chosen by them and not be adobe. Adobe offerred options; apple selected from those options. So blame Jobs for Courier as the monospace family and for Times(12) as the serif family. And for Helvetica as the Sans family. -JimC -- James Cloos OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc
Re: [Groff] MIssion statement
>>>>> "MB" == Mike Bianchi writes: MB> Occasionally I use the hack of extracting the PostScript with MB> pdf2ps(1) and then use ps2pdf12(1) to turn it back into PDF. If you want ghostscript to re-create a pdf, you can pass the pdf directly to ps2pdf. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [Groff] MIssion statement
>>>>> "RC" == Ralph Corderoy writes: RC> To confirm we're all using the same bytes, RC> $ curl -sS http://www.gnu.org/software/groff/groff-mission-statement.pdf | >> sha1sum RC> 93cc5719150cfa2a74fbd265e26cb3876529b4b6 - Has it been updated since this started? I get c2f7a1b7bd3eac6e764c81855b00dde7f11b7af5. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [groff] Problems with -Thtml
>>>>> "BM" == Blake McBride writes: BM> Greetings, BM> I composed a user manual with MM. Looks great. BM> I now need an HTML version. I tried: BM> groff -Thtml -mm build-manual.mm >build-manual.html That works fine on my workstation, which is still at groff 1.22.3. Ie, the pdf and html version look the same. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [Groff] Re: OTF fonts
>>>>> "Denis" == Denis M Wilson <[EMAIL PROTECTED]> writes: Denis> 4b. Or keep the TYPE1 file and put name in devps/download Denis>(big output!). Rather than use the type1 file here I'd use a type42 version of the original ttf font. I'd use ttftotype42(1) from the lcdf typetools at http://www.lcdf.org/type/#typetools Also, when using otf fonts, you can use cfftot1(1) from that same package to create a type1 font to pass to afmtodit(1) and to include in the postscript output. (The type42 format is a pfa-like wrapping of a ttf which can be included in a postscript stream just like a pfa type1 font can.) I'd use something like: ttf2pt1 -a -e DejaVuSansMono.ttf DejaVuSansMono ttf2type42 -o DejaVuSansMono.t42 DejaVuSansMono.ttf then run afmtodit on the resulting DejaVuSansMono.afm file and finally I'd add: DejaVuSansMono DejaVuSansMono.t42 to the download file in the devps directory. Hmmm I see that the grops(1) man page suggests using ttftot42 from: ftp://www.giga.or.at/pub/nih/ttftot42/ which can generate both the type42 file and the afm in one go. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6
Re: [Groff] Re: OTF fonts
>>>>> "Jeff" == Jeff Zhang <[EMAIL PROTECTED]> writes: Jeff> Anyway, direct font support is more favorite than the converted Jeff> ones, similiar is xelatex vs cjkutf8. No disagreement there! I'd also love to see full libhnj support. (Probably should have two registers, one for choosing the libhnj hyphenation algorithm and a second one to choose the line breaking algorithm. Just to ensure old documents do not reflow unless one asks for the new algos.) -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6
Re: [Groff] groff -mm output something I don't expect
>>>>> "Luke" == Luke Huang <[EMAIL PROTECTED]> writes: Luke> and opened it with ``evince'', then I found there are two short Luke> bars in topleft and topright corners of the page. What version of evince? It works fine for me, using svn trunk evince (my last compile was of revision 3248), git master libspectre (same as the 0.2.1 release) and ghostscript 8.63 (libspectre links to libgs). -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6
Re: [Groff] Replacing groff with troff?
>>>>> "DMW" == Denis M Wilson writes: DMW> It's a reminder never to use BSD... On a cursory reading, DMW> it wasn't clear how mdocml produces printable output. My impression is that they don't intend it to, that those who want printable output should install groff (or perhaps heirloom?) from the ports tree. They only seem to want mdocml to create cat files from mdoc and man src. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [Groff] Misplaced glyphs
>>>>> "AGR" == Ali Gholami Rudi writes: When I tried this, using groff-1.21 as packaged by gentoo, I got reasonable output for -Tps and -Tdvi for most of the text. Only the lc, lf, rc, rf chunk had bad alignment. AGR> Bad ... large brackets lc, lf, rc, rf, AGR> \b'\(lc\(bv\(lf' \b'\(rc\(bv\(rf' That rendered with the extensions narrower than the upper and lower bits, essentially matching the rendering in you pdf. The problem seems to be the use of CURLY BRACKET EXTENSION between SQUARE BRACKET UPPER CORNER and SQUARE BRACKET LOWER CORNER glyphs. Ie, \(bv is not the correct extension (empirically) to use between the \(lc \(lf and \(rc \(rf pairs. Everything else, though, looked fine. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [Groff] need help with composite glyphs
>>>>> "HO" == Heinz-Jürgen Oertel writes: HO> If not absolutely necessary, I like to stay with my ISO 8859-1 (-15) environment. In a utf-8 locale, nroff defaults to the utf8 device, which is why the nroff example as written did not work for you. It seems that you need support for u0075_030A in the groff font file if you want to use the unicode combining sequence. This: :; grep u0075_030A /usr/share/groff/1.22.2/font/*/R /usr/share/groff/1.22.2/font/devhtml/R:u0075_030A 24 0 0x016F /usr/share/groff/1.22.2/font/devutf8/R:u0075_030A 24 0 0x016F shows that only those two devices have it by default. The aring example worked because the font/devps/TR file has explicit support for the type1 /aring glyph. It also support the /ring glyph, so maybe something like: \o'u\C\'ao\'' is the way to go? \o'' overstrikes up to nine glyphs; \C'ao' is the ring glyph. It works here for ps, dvi and pdf devices. But only for troff; nroff only show the last glyph from the \o'' set. (I used http://cm.bell-labs.com/sys/doc/troff.pdf to learn \o'' and \C'' and looked at /usr/share/groff/1.22.2/font/devps/TR to find the roff name (ao) for the ring glyph.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [Groff] need help with composite glyphs
>>>>> "WL" == Werner LEMBERG writes: WL> Th[e] [/uring] glyph is only contained in the URW fonts. It would be useful were the \[] construct, if the NFC glyph is unavailable but the NFD constituents are, to use the same mechanism as \o'' to construct a fallback for the desired glyph. Also, I see that preconv converts ů to \[u016F] and ů to u\[u030A], neither of which fall back to overlaying \u and \ring when needed; and the sequence fails to work even with a font like U-T. (Had more to say, but have to run for a few hours) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
[Groff] git gc
Using try 2, after git fast-import, du(1) shows: 260444 groff-git/.git/objects/pack after git gc --aggressive, that becomes: 11632 groff-git/.git/objects/pack -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [Groff] Back to the future
A reasonably small update, which would demonstrate what can be done, might be to port GNU fmt(1)’s paragraph algorithm to groff’s nroff. (It is based on TeX’s, but simplified for character cell terminals. As such, it should be a perfect fit for nroff and provide a hint of what could be done for troff.) The project should be suitable for GSoC. Proper neqn(1) support also would be useful. There should be suitably licensed code available which could be ported for groff. Perhaps from the now gpl2 plan9? Or from heirloom? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [Groff] Mission statement, second draft
>>>>> "DMW" == Denis M Wilson writes: DMW> Oh, and the PDF document above was beyond my version of Firefox's DMW> ability. I downloaded it: gv fails, finding errors and showing all DMW> the wrong glyphs; evince showed it fine but a page at a time. I DMW> regret to say that Adobe reader was the only one that correctly DMW> rendered as two-up. If you mean Gunnar's just.pdf, that is pdf 1.4 (produced from the heirloom troff postscript output by, it says, GPL Ghostscript SVN PRE-RELEASE 8.57). Nothing in it should be new or unusual enough to cause problems for any pdf reader released in the past decade. Something must have been misconfigured or buggy for it to fail. Does your distribution have recent versions? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
[Groff] gnuplot
Gnuplot would like an example document showcasing troff+pic, using gnuplot's gpic terminal to generate the pic, for regression testing. Does anyone have one handy? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [Groff] `fi' makes trouble in pdf
>>>>> "RC" == Ralph Corderoy writes: RC> How do you recommend `disassembling' a PDF to inspect its contents? I like mupdfclean from mupdf best. Call it with the -d option. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [Groff] `fi' makes trouble in pdf
>>>>> "BW" == Bernd Warken writes: BW> You are right. The error come from my OS. Certain versions of fontconfig (upstream) included the TeX GYRE fonts as suitable options for (some of) the base postscript font names. The GYRE fonts use names like /f_i for the ligs, not like /fi. They do so better to ensure than the text can be un-ligated when selected or otherwise converted to text. Groff, of course, expects the glyph names used by the original Adobe fonts. And it is right to do so. Fontconfig has since removed mention of the GYRE from those sections of the default configs. Distributions will catch up eventually. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [Groff] Are your gropdf and pdfmom man pages installed?
>>>>> "DK" == Dave Kemper writes: DK> I finally updated my system-wide groff installation from 1.21 to DK> 1.22.2. I notice that two man pages new in 1.22.2, those for gropdf DK> and pdfmom, were not installed in the upgrade. I looked at the build log for sys-apps/groff-1.22.2.ebuild. For the man pages which do get installed, there are lines which match the regex /^Making.+man/. There are none for those two pages. And, indeed, there is no reference to gropdf.man or pdfmon.man anywhere in the build log. Git master, however, does have those lines. And does install the two man pages. So this looks fixed in master. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [Groff] Are your gropdf and pdfmom man pages installed?
>>>>> "DK" == Dave Kemper writes: DK> I'm not certain what file you mean "does have those lines." Before that DK> paragraph, you were speaking of a build log, I was talking about the build log. Not having those Making lines means that the build doesn't create the man files which make install would install. DK> And Gentoo's groff-1.22.2.ebuild script doesn't make direct DK> reference to any man pages. My point is that groff has fixed the bug in its git sometime since 1.22.2 was released. I didn't bisect to determine what the fix is, and therefore what a useful patch for 1.22.2 would be. DK> It's also not clear to me whether the "git master" you're referring DK> to is the groff git master or a Gentoo one. git://git.savannah.nongnu.org/groff.git -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [Groff] Are your gropdf and pdfmom man pages installed?
>>>>> "IS" == Ingo Schwarze writes: IS> Building groff-1.22.2 from the release tarball on OpenBSD, IS> i do have the two lines IS> Making gropdf.n from gropdf.man IS> Making pdfmom.n from pdfmom.man In that case my conclusion was wrong. The problem then must be gentoo's patch to enable parallel builds. But I tried a parallel build when I built master, Gentoo's parallel-mom patch will not be required for future releases. Of the two commits Dave noted, 290eaaac6cfc, *is* the Gentoo patch in question, and so 681919b36d47 also should get added to the ebuild. I update the gentoo bug (https://bugs.gentoo.org/show_bug.cgi?id=487276) with a note about that, but do not have enough privs there to reopen it. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
