groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Re: ESC/P2 printer driver


From: Werner LEMBERG
Subject: Re: [Groff] Re: ESC/P2 printer driver
Date: Mon, 03 Nov 2003 15:35:04 +0100 (CET)

> So far, I've taken tty.cpp and stripped out:
> * All colour handling

Hmm, make_rgb_string() is still there.

> * Inverse video and other terminal-specific code
> * All of the old_drawing_scheme stuff

You should also remove UTF-8 handling (this is, everything related to
`is_utf8').

> What is the project policy WRT the C++ Standard Library, templates
> and namespaces?  Is it OK to use std::string, std::vector etc?  I
> noticed ptable.h uses macros where templates could be used to make
> the code cleaner (you might even be able to use std::map
> internally), i.e.:
>
> template<typename T>
> class ptable {
>   std::map<std::string, typename T> m_table;
> };

Please neither use templates nor namespaces.  (Some people on the
groff list will start howling, I know :-) And I fully agree that
ptable.h is a mess.  I'm *really* conservative here.  There are still
old C++ compilers in use which don't support those `new' features
properly.

> In the font file (font/devescp/R.proto) I have specified the numeric
> codes for a whole set of characters, including accented chars,
> symbols, Greek and mathematical symbols using the two-letter symbol
> code, for example:
>
> ~n    24      0       0244
>
> Do I also need to specify an additional line, like this:
>
> ñ     "
>
> for the latin-1 equivalent, or will groff convert automatically?

No.  *Only* use groff symbols, either from the Groff Glyph List (GGL)
or algorithmically derived.  Details can be found on the groff_char
man page and in groff.info, section `Using Symbols'.  Input character
codes are mapped with files like latin1.tmac or latin2.tmac to
symbols.

> What happens with utf-8 input?

Utf-8 input is not supported yet.  It is on my TODO list since
ages :-(

> Another thing the printer provides is a whole set of line drawing
> characters.  I should be able to use those by replacing the unicode
> line drawing chars in crossings[] etc.

Yes.  They should be probably directly accessible with groff symbols;
either use already available entities from the GGL or the `uXXXX'
entity names based on Unicode.

> One thing I'm unsure how to implement are some of the special
> character sets the printer supports.  By loading selecting different
> country codes in the printer, a series of ASCII codes become
> different characters (e.g. # -> £, ] -> Å).  They have the same
> number, however, so I can't put them in the DESC file.  To access
> one of these chars means selecting a non-US country, printing the
> code, and then selecting US again.  What is the best way to
> accomplish this?  Some printers also have multiple selectable
> [entire] character sets.

What about something like this in the `R' file, using the higher bits
to select the character set:

  0x0000-0x0XXX  ... primary character set
  0x1000-0x1XXX  ... national character set #1
  0x2000-0x2XXX  ... national character set #2
  ...

You can choose whatever representation you want; those glyph indices
are only seen by the escp driver.

> tty.tmac contains a some macros I want, but it also has some I need
> to redefine or unset.  If I create an escp.tmac and include tty.tmac
> in this, will this get loaded automatically when I use -Tescp as the
> output device?

This is controlled in `troffrc' via the \*[.T] string.  For simplicity
I suggest to copy everything into a new `escp.tmac' file, not loading
`tty.tmac'.

> I've attached a preliminary copy of what I've done so far.  Does
> this look OK WRT the Makefile changes etc.?

After a quick look I think that everything is fine!


    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]