Hi Branden,
It is with a heavy heart that I announce I shall be leaving the groff mailing
list, I'm finding it too much work. Yesterday, you managed over 2900 words in
approx 80 minutes whilst also doing a code review, and probably 3 other things
as well! I am so jealous my paltry sub 10 words a minutes (on a good day) just
can't cope, particularly as you sometimes have difficulty getting the points I
am trying to make and reply with points which are not relevant. An example was
your "unease" with adding an extra field to afmtodit output, you pointed me to
some documentation rather than a swift perusal of the code in afmtodit where
you can see that it ALWAYS outputs 5 tab characters and never outputs -- so no
comments. And talking of "unease", you wrote, in reply to my request for help
with merging: "Sure. Once we're _both_ happy with it! :D", and this was
eight months ago, so unease really does mean rejection. In November it
became:-
> > 1. Changing the format of font description files to add yet
> > another field, mapping character names to Unicode code points.
> > In the rest of groff, this is not necessary because we have
> > glyphuni.cpp.
> >
> >
> > https://git.savannah.gnu.org/cgit/groff.git/tree/src/libs/libgroff/
glyphuni
> > .cpp
> >
> > I'd like to honor the DRY principle here. What's a good way
> > to achieve that?
Given that afmtodit does not use glyphuni.cpp (and can't) the DRY principle
here means to let afmtodit plant the needed data in the font files for gropdf
to use, but you didn't seem to see how irrelevant your comment was.
Anyway, enough of this useless banter. This is a joyful moment, I'm freeing up
so much time to pursue other projects that will be equally rewarding as
writing gropdf has been, like:-
Detection of bias in UK news channels
In the UK there is a legal obligation for "Due impartiality and due accuracy"
(https://www.ofcom.org.uk/tv-radio-and-on-demand/broadcast-codes/broadcast-code/section-five-due-impartiality-accuracy).
For the past 4 years, I have
been converting the dvb-t subtitles for news channels into text using an OCR
program I wrote. It's about time I fooled around with the data using NLP and
see if it is possible to detect bias within the data, at a minimum I can
extract statistics on the political persuasion of guests, but I've got a
feeling I might be able to go further.
GB News, a right wing channel, keeps getting fined. I'd love to be able to
write something which automatically emailed a complaint to Ofcom if it caught
them breaking the rules, without having to watch the channel all day. :-)
My autobiography
Well, I've got the title - "A life more ordinary"!!
If I ever get the gropdf itch in the future, this is my todo list:-
A) Underlining text.
Peter asked if I could do this, ages ago because he has a method for
postscript, from Tadziu. It is half done.
B) Watermarking
Given a pdf scale to full page size and place it under the groff output, or
stamp, put it above it. I have worked out the last wrinkle. Normally, if you
rotate the page with -P-l any pdfpic will be rotated as well, so that the
picture orientation stays with the text orientation but the watermark
orientation is controlled by the page orientation.
C) Ttf/otf in pdfs
This is a lot of work, but I was starting to get a handle on it. Incidentally,
if I ever do get this done, the Tibet ligatures issue will be solved. The
reason it seems to be Ok everywhere else except in groff, is because the
"rules" for the ligature placement/resizing are in sub-tables within the ttf
font file, but in the fontforge conversion to a pfa file most of this
information is discarded because type 1 fonts have no concept of vertical
adjustments so all that gets through is the horizontal adjustment which
ensures the glyphs print over each other, but without the correct vertical
adjustment/sizing. Still a lot of research to do.
I've just seen your last email with a lot of nice things, but sometimes you
confuse "code review" with "design review". If someone wants to know how to
get to the doctor it is not helpful to say "Well I would not start from here”.
I have told you right from the beginning that all I needed was a way to pass
anything to gropdf, and so I coded on the expectation I could receive anything
and dealt with it appropriately. This is all working code. Later you expressed
a preference for a method where you would clean the data within troff so I
would not need to, but I already had working code and so far any alternative
is vapourware, and the only pseudo code I've seen (a for loop with a flag to
indicate whether the next item is a node or a character), with the expectation
that nodes will be discarded, would not cut the mustard because I believe
special characters (i.e. \[u] or \[em]) are actually held as nodes within
troff so would be discarded as not a character. So the criticism is of my
design, hardly what I call a code review and
