[Groff] Re: MSVC Port--LaserJet Issues

[Werner LEMBERG]

> > > Most of the new printers are 1200 dpi.  I've actually used res
> > > 2400 and unitwidth 3175 (to work at the printer's internal
> > > resolution) since 1.11, with good results.  So far, at least, I
> > > haven't found a snag.
> >
> > Shall I recommend this in grolj4.man?
>
> It seems OK to me--but if so, I'd probably also set the DESC file up
> that way as well.  It appears that things are fine as long as
>
>     resolution x unitwidth = constant
>
> at least up to the LaserJet's internal resolution.

Do all LaserJets user the same internal resolution?  I know that the
printers can be adjusted to use a certain DPI.  In case they receive a
request to do a movement finer than the DPI allows, what is happening?
Does the printer automatically round to the nearest valid value?

What about making the resolution for groff identical to the internal
LaserJet resolution?

> Thanks.  Since I don't have tex, I was about to ask if a PDF was
> available.

It's not completely up to date but the additional modifications are
minor corrections only.

> > I'm not sure yet how to handle the glyphs for devlj4 which can't
> > be represented by Unicode.  Will have to think about it.
>
> Every glyph that I put in my devlj4 font files has a Unicode
> mapping, according to the list I got from HP, although some of the
> glyphs may be in the private area.

I don't want to use the PUA for glyph indices, this is, I don't want
to have groff glyph names of the form `uXXXX' with `XXXX' from the
PUA.  This should be really reserved to the user.  In general, I
consider the approach of HP to use MSL numbers better than using
Unicode character codes.

According to the stuff I have collected, the following glyphs don't
have a Unicode mapping (sorted by MSL -- please correct them if I'm
wrong):

  # 603 middle curvature integral
  # 604 top left summation
  # 606 bottom left summation
  # 607 bottom diagonal summation
  # 616 top right summation
  # 617 middle summation
  # 618 bottom right summation
  # 619 top diagonal summation
  # 623 mask symbol, superior
  # 644 middle double bracket
  # 648 extension large union/product
  # 649 bottom large union
  # 650 top large intersection
  # 651 top left double bracket
  # 652 bottom left double bracket
  # 657 bottom large bottom product
  # 658 top large top product
  # 659 top right double bracket
  # 660 bottom right double bracket
  # 666 double horizontal arrow extension
  # 667 complement of #617
  # 1034 service mark, superior

For the glyphs in the following list I couldn't find something
adequate in the Unicode standard:

  # 222 thick horizontal mark
  # 605 double vertical line, composite
  # 640 power set symbol
  # 684 lozenge, diamond -- U+25CA ?
  # 1110 medium open bullet
  # 1113 visible tab
  # 1116 visible end-of-file
  # 3812 ornament, apple

My idea is to add support for unnamed glyphs to hpftodit (in case you
haven't done this already in your changes; will look at your code
shortly).  Then the user can directly access the glyph with \N'...',
using the .char request to define a name if he or she wants to.  Do
you think that any of those glyphs actually *deserves* a name?  I
mean, which of those glyphs could be useful in general, probably be
emulated on other devices?

As a summary, unnamed glyphs should be used for glyphs which either
don't have a Unicode mapping (see list above) or which are mapped to
the PUA in the font itself.

> I have integraltp and integralbt in my devps as well.

You might try the new version of afmtodit which supports the complete
AGL -- including integraltp and integralbt.


    Werner