summaryrefslogtreecommitdiffstats
path: root/contrib/groff/grohtml/TODO
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/groff/grohtml/TODO')
-rw-r--r--contrib/groff/grohtml/TODO294
1 files changed, 294 insertions, 0 deletions
diff --git a/contrib/groff/grohtml/TODO b/contrib/groff/grohtml/TODO
new file mode 100644
index 0000000..4924bd1
--- /dev/null
+++ b/contrib/groff/grohtml/TODO
@@ -0,0 +1,294 @@
+
+------------------------------------------------------------------
+ T O D O L I S T
+------------------------------------------------------------------
+finish working out the max and min x, y, extents for splines.
+------------------------------------------------------------------
+check and test thoroughly all the character descriptions in devhtml
+(originally taken from devX100)
+------------------------------------------------------------------
+improve tmac.arkup
+------------------------------------------------------------------
+also improve documentation.
+------------------------------------------------------------------
+fix the bugs which are exposed by Eric Raymonds pic guide,
+"Making Pictures With GNU PIC". It appears that grohtml becomes confused
+about which sections of the document are text and which sections need
+to be rendered as an image.
+------------------------------------------------------------------
+it would be nice to modularise the source. A natural division might be
+to extract the table handling code from html.cc into table.cc.
+The table.cc could be expanded to recognise output from tbl and try
+and generate html tables with lines/rules/boxes. The code as it stands
+should cope with very simple plain text tables. But of course at present
+it does not get a chance to do this because the output of gtbl is
+bracketed by \fCgraphic-start\fR and \fCgraphic-end\fR.
+------------------------------------------------------------------
+introduce anti aliasing for the images as mentioned by Werner.
+------------------------------------------------------------------
+improve generation of html. Perhaps by using a stack of current
+html commands and using a kind of peephole optimizer on the stack?
+Certainly the html should be buffered and optimized.
+------------------------------------------------------------------
+
+
+Informal to do bug list and done list
+=====================================
+
+This very informal and I've included some comments. Mainly consists
+of a emailed bugs and wish lists. All very useful and welcome.
+
+------------------------------------------------------------------
+Dean writes: (provinsd@enf403-2.ensu.ucalgary.ca)
+
+I noticed also that the TOC appears immediately after the title, splitting
+it from the author and abstract. Any chance it can be moved down?
+
+gaius> this should be straight forward. (Not done yet though)
+------------------------------------------------------------------
+
+.) The command `\(->', translates to the `registered' sign (or rather
+ the character `0xAE') instead of a right arrow.
+
+--nearly fixed-- 4/01/2000
+
+gaius> if we know the standard html character encoding for farrow which
+gaius> will work on *all* browsers then this can be fixed inside devhtml/TR
+gaius> etc. Otherwise I guess we could translate this character into ->
+gaius> in tmac.html ?
+
+------------------------------------------------------------------
+
+Werner writes:
+
+Nevertheless, still some bugs in it. As usual, I'm refering to man.1
+of the mandb package; my command to create man.html was
+
+ groff -U -t -man -Thtml -P-r -P200 man.1 > man.html
+
+.) The `-w , --where, --location' node at the beginning of man.html
+ shouldn't be there at all.
+
+> .) Some paragraphs still contain hyphenated words (e.g. first
+> paragraph of the `DESCRIPTION' section).
+
+Oops! Please ignore this. I forgot to include `-mhtml' :-)
+
+.) Is it possible to have anti-aliased PNG images?
+
+.) The item `man --help' in the `EXAMPLES' section doesn't start a new
+ paragraph.
+
+.) In the description of the -r switch (in the `OPTIONS' section),
+ there is a new paragraph in the middle of a sentence.
+
+.) What about centering the images? Or does it depend on the table
+ itself?
+
+gaius> yes, grohtml places images at their relative position on the page.
+
+.) In the `OPTIONS' section, `-c, --catman' and `-d, --debug' are
+ glued together which shouldn't happen.
+--fixed--
+
+.) Sometimes, an empty line is missing between items, e.g. between the
+ description of the -e and the -f options.
+
+.) After the `-w, --where, --location' line, there is a superfluous
+ empty line.
+
+.) The indentation in the `FILES' section is inconsistent. The same
+ is true for `-V, --version' a few lines above.
+
+.) The formatting of the paragraph after the first table is completely
+ wrong. It appears that the first few words are set in two columns;
+ additionally, the indentation is incorrect.
+
+.) Similarly, the description of `-l' in the OPTIONS section is
+ idented incorrectly. Wrong indentations happen still quite
+ frequently.
+
+.) In the description of the `-D' option, there is a blank line in the
+ middle of a paragraph.
+
+
+ Werner
+
+------------------------------------------------------------------
+Werner writes:
+
+Gaius,
+
+checking a weird man page written by myself in German (using German
+hyphenation patterns also :-), I found some more bugs:
+
+.) Look at the following:
+
+[\c
+...\^\c
+]
+[\c
+.BI -P \ \%Plattform-ID\^\c
+]
+
+ This translates to
+
+[<font size=3><B>-E</B> <font size=3><I>Kodierungs-ID</I> <font size=3>]
+ ^
+ (groff breaks the line after the final `]'.)
+
+ There are two errors in it: First of all, the `\ ' command should
+ be translated to `&nbsp;'. Secondly, a blank has crept in (marked
+ with `^'. Apparently, this is related to whether it is the last
+ item of a line or not.
+
+--fixed-- 4 01 2000
+------------------------------------------------------------------
+
+from Steve Blinkhorn <steve@prd.co.uk>
+
+One thought that came immediately to mind after our first trials.
+If grohtml depends on grops, should there not be an easy interface to
+allow PostScript code to be interpreted into the output? For
+instance, we generate our letterhead, including a logo, on the fly in
+groff. The logo is pure PostScript. We use PostScript for colour
+manipulation, and recently for generating a lot of graphics for
+printing.
+
+gaius> should be interesting - if we can generate PS then GS it
+gaius> we should be in business
+
+------------------------------------------------------------------
+ D O N E L I S T
+------------------------------------------------------------------
+the logical place and name for a file describing tmac.arkup is
+groff_markup.man placed into the `tmac' subdirectory, and your html.ms
+looks like being this kind of file.
+
+So I won't check it in currently -- may I ask you to convert this file
+to a man page?
+
+-- fixed --
+
+Another related problem: I can imagine that a lot of people start to
+write man pages with HTML output in mind also. Nevertheless, it
+should be still possible to display such pages correctly with a plain
+text man pager. As a consequence, such man pages should contain at
+the beginning something like
+
+ .do mso tmac.arkup
+
+What do you think?
+
+ Werner
+
+-- fixed --
+gaius> fixed by using troffrc-end I believe
+--------------------------------------------------------------------
+Gaius,
+
+in troffrc, it appears to me that tmac.html is loaded if the output
+device is HTML. So why must I load it again (using -mhtml) to
+suppress hyphenation for HTML output? Can you provide a fix for this?
+
+ Werner
+
+gaius> fixed as above
+--------------------------------------------------------------------
+
+from (daeschler@shuttle.de) Rainer Daeschler
+
+I recognized s problem limiting the usage for
+"none-english aliens". The generation of PNG of GIF,
+skips all special characters like
+
+ äöü ÄÖÜ ß
+
+French, Spanish, and Scandinavian national letters, too.
+
+--fixed-- 14/01/2000
+
+An option which forces tables into HTML-code instead of building
+an image would be most valuable. Of course it would not preserve
+the original layout in many cases, but ease modifications of
+the HTML-output to the users demand afterwards.
+
+--fixed-- 14/01/2000
+
+gaius> use the new -T option to grohtml (-P-T to groff)
+
+-----------------------------------------------------------------
+from Werner
+
+ but `pre-defined' appears as `pre&shy; line' (note the space
+ character after the soft hyphen). Something in the code makes
+ problems here...
+
+ (IIRC, I've sent you this man.1 file a few weeks ago).
+
+gaius> Werner fixed this by adding .cflags 0 -\(hy\(em\(en to tmac.html
+
+-----------------------------------------------------------------
+from Werner and Eddie
+> > > .LP
+> > > .URL Germany "ftp://groff.ffii.org/pub/groff/"
+> > > |
+> > > .URL USA "ftp://ftp.gnu.org/gnu/groff/"
+> >
+> > Problem: the first "|" of each line is missing a leading white space
+> > space.
+> >
+> > How to ensure the spaces get put there?
+>
+> This is a feature grohtml (unfortunately -- AFAIK, Gaius hasn't found
+> a good workaround yet). HTML stuff gets written as specials which
+> don't consume space for troff, causing some miscalculation if placed
+> at the beginning of a paragraph. A workaround is to write
+>
+> .LP
+> \&
+> .URL ...
+> |
+> .URL ...
+
+gaius> fixed by adding \& to HTML as per Werner's suggestion
+
+
+Werner writes:
+
+PNGs created by grohtml have apparently a white background -- isn't it
+possible to make the background transparent optionally?
+
+Another suggestion: What do you think about calling the PNG files
+<groff_input_file>-<index>.png or something like this? I can't see an
+advantage in the current naming scheme except for debugging purposes
+where it may be necessary to stay with the old files.
+
+--fixed-- 04 01 2000
+
+gaius> however I've had to retain a default grohtml-pid-index.png for all
+gaius> stdin as we don't know the filename.. sadly looks like everything..
+gaius> Nearly done by including a new tcommand 'F filename'
+
+--fixed-- 26 01 2000
+------------------------------------------------------------------
+
+.) The following code produces ugly results -- is it possible to make
+ the HTML result similar to the ascii output?
+
+.in +4m
+.ta 3iC
+.I "Plattform Plattform-ID (pid)"
+\&.sp
+.ta 3iR
+Apple Unicode 0
+.br
+Macintosh 1
+.br
+ISO 2
+.br
+Microsoft 3
+.PP
+
+--fixed-- 14/01/2000
+------------------------------------------------------------------
OpenPOWER on IntegriCloud