I've had some success sending a single-page HTML to my Kindle. The Kindle will
only accept HTML pages that have no dependencies on external files, i.e., no
external CSS, and no external image files, both of which problems can be
solved. HTML is obviously nicer than PDF on the Kindle because the
"Pointage"? Like mileage, footage, poundage ...
--d
Sent from Yahoo Mail on Android
On Sun, Apr 18, 2021 at 9:39 PM, Bjarni Ingi Gislason
wrote: Bug #60403 (closed) unified the writing of "point-size" to "point
size".
The problem is,
that this coinage does not make sense.
The "poin
d the list because what I have to ask you is
important. I used to work in software licensing compliance
professionally, so perhaps I am extra paranoid.
At 2021-01-14T06:05:41+0000, Dorai Sitaram via wrote:
> Absolutely, do add whatever license is needed; and modify what I have
> (bo
Absolutely, do add whatever license is needed; and modify what I have (both
code and documentation) to suit groff's standards. My repo is purely temporary
and meant to ferry the code to you better than email can.
--d
On Thursday, January 14, 2021, 12:32:19 AM EST, G. Branden Robinson
wro
I'm used to single-spacing by now, given its ubiquity, but surely the Germans
carry their disdain for typographic breathing space a little too far? As in the
posted article, paragraphs are difficult to visually separate, lacking as they
do both leading horizontal indentation and vertical separa
Thanks, John! Just what I was looking for (but didn't know how to search for).
--d
On Friday, January 8, 2021, 05:19:12 AM EST, John A.
wrote:
On 2021-01-08, Dorai Sitaram wrote:
> What's a good way to put a bit of text in the left margin of the
> "current" line?
With ms, I would d
sentence-final periods?
Ricky
> On Jan 6, 2021, at 11:44 AM, Dorai Sitaram via wrote:
>
> Thanks, Doug! I've updated https://gitlab.com/ds26gte/groff1345 to include
> your suggestions 2 and 3.
>
> I am not at all confident that the man page I've added hits the rig
Thanks, Doug! I've updated https://gitlab.com/ds26gte/groff1345 to include
your suggestions 2 and 3.
I am not at all confident that the man page I've added hits the right notes or
even uses the correct terminology, but the community can easily correct it to
meet its standards.
--d
O
tence in
1999, but the rouble...?
I've added these into the latest https://gitlab.com/ds26gte/groff1345
--d
On Monday, January 4, 2021, 10:43:53 PM EST, Dorai Sitaram via
wrote:
To avoid emailing updated versions of rfc1345.tmac, I've created a temporary
Git repo
htt
On Monday, January 4, 2021, 03:12:42 PM EST, Dorai Sitaram via
wrote:
Indeed it doesn't. (TBH, I've never warmed to the single-character ellipsis
as it seems too narrow in most fonts.)
I notice Vim's digraph system (which is based on RFC 1345) uses the digraph ,.
(comma-follow
ng that it is not in
groff either considering groff was originally written by a British
person.
It is available as \N'188' in the symbol font or as \[u2026].
Denis
On Mon, 4 Jan 2021 05:20:26 + (UTC)
Dorai Sitaram via wrote:
> Enclosed is my draft for does.tmac.
>
>
&g
Enclosed is my draft for rfc1345.tmac.
--d
On Sunday, January 3, 2021, 09:27:06 PM EST, Dorai Sitaram via
wrote:
I'll be happy to write up an rfc1345.tmac and send it to you. I don't think
it requires a tremendous amount of maintenance, as the list of mnemonics
appe
At 2020-12-14T19:07:06+0000, Dorai Sitaram via wrote:
> s.tmac defines a bunch of strings to display extra glyphs if the user
> calls the .AM macro. Most of these glyphs are already available with
> standard glyph names, and, as far as I can tell, the only new glyph
> defined is the ho
I'm not completely sure it's true for all modern applications, but I hope
you're right that it doesn't hurt in general to explicitly type two spaces
after a sentence. As a dinosaur, that's what I used to do, but trained myself
out of it after reading a high-profile tirade scolding me (at least
Ha! Glad I'm not the only one who is driven up the wall by newlines at the end
of every sentence. I've heard this policy touted so many times by folk who are
obviously expert (even those who don't troff), and I have no doubt at all it
works for them.
I just can't read or edit it to save my l
Thank you, Keith!
--d
On Thursday, December 17, 2020, 12:48:35 PM EST, Keith Marshall
wrote:
On 17/12/2020 14:37, Dorai Sitaram via wrote:
> Wow, this (Oliver's suggestion) actually works. ...
I don't know why I even bother!
https://lists.gnu.org/archive/html/
Wow, this (Oliver's suggestion) actually works. I get a bunch of diagnostics
like this:
Use of uninitialized value $file in substr at /usr/local/bin/gropdf line 615,
<__ANONIO__> line 95. Use of uninitialized value $name in concatenation
(.) or string at /usr/local/bin/gropdf line 621,
Thanks Dave, for the suggestion. That doesn't seem to be the problem, however,
on my machine (Ubuntu 20.10). No-argument cat works as expected.
--dOn Tuesday, December 15, 2020, 04:50:01 PM EST, Dave Kemper
wrote:
On 12/15/20, Oliver Corff wrote:
> I have no other version at hand so
he request .rd works as expected.
Oliver.
On 15/12/2020 19:59, Dorai Sitaram via wrote:
> groff.texi mentions the request .rd that's supposed to read user input
> mid-run, but I can't seem to get it work at all. No prompt, just quite
> ignoration.
>
>
> --d
>
groff.texi mentions the request .rd that's supposed to read user input mid-run,
but I can't seem to get it work at all. No prompt, just quite ignoration.
--d
s.tmac defines a bunch of strings to display extra glyphs if the user calls the
.AM macro. Most of these glyphs are already available with standard glyph
names, and, as far as I can tell, the only new glyph defined is the hooked o,
(equivalent to Latin small letter o with ogonek). Both a string
Is the problem here really an error in syntax highlighting? I don't know the
intricacies of -mom, but it seems rather that the incorrect style of comment
(the one that eats a newline) was being used here. Eschewing syntax
highlighting would have brought the author no closer to recognizing thi
The 5/6 may be a relatively recent consensus based on peer monitoring. UTP
doesn't mention 5/6, for instance. It has its own (slightly less) strange
fraction though: 11/12 (see p. 606). When it came to FL, it was a Wild West out
there back then, I tell ya.
--d
On Sunday, November 15, 20
Is there a recent version of the script 'fixmp' mentioned in the MetaPost
documentation? (It allows groff to accept MP-generated PS files.)
Google points me back to these archives for a 2006 version that no longer works.
Thanks--d
UTP strongly hints that the -ms macros have the end-of-input trap .em pre-set
to a defined macro called .EM, with the implication that if the user wants to
affect end-of-input behavior they can append or prepend to this macro rather
than messing with .em directly. However groff's s.tmac sets its
Is there a way to change the text used for the section header inserted by
'refer' before the accumulated references? By default, it is "References".
Hopefully it isn't hardcoded.
--d
I have GROFF_ENCODING set to utf8, but this only works for the main file
processed by groff, not to any subfiles that are sourced via .so .
Giving the -s option to groff to force a soelim doesn't work either.
Adding the -k option to force a preconv, whether before or after the -s option,
doesn'
Branden,
That's a pretty good guide. Thank you for your effort!
When you say points are '(about 1/72")', it probably doesn't hurt to go the
extra mile (!) in precision and say '(1/72.27")'. It's shorter (no need for
'about') and more correct. Also I would spell out inches here, as the
double-pr
I have some some Unicode characters with codes higher than 256 (e.g., smart
quotes) that 'refer' chokes on with the message "invalid input character code".
Is there a way to tell refer to just pass them through to stdout? The error
happens even if the offending characters don't occur inside th
29 matches
Mail list logo
