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

Re: MF hackery (arrow kit)

Ulrik Vieth wrote:
> > I have tried |zero_width|, but that did not correctly center the 
> > glyph. Now I use an explicit |adjust_fit| to cancel the width.
> 
> Should be fine, if it solves the problem.  However, it would be
> interesting to find out why |zero_width| didn't work as expected.

If I interpreted the outcome of my short experiment with |zero_width|
correctly, it let's glyph bitmap hang out to the right. This is what you
need for the \not glyph, but I want the negations in the arrowkit to 
be centered, since they are placed between two glyphs, not overlaid.

> >> * The gaped squiggly arrows produce some stray pixes within the 
> >> are that should be erased.  Anyone knows how to fix this???
> 
> > Instead of |unfill|ing a box, I now calculate the intersection point
> > and draw a shorter spline. This eliminates the stray pixels and gives
> > correctly rounded endings.
> 
> This sounds like a better approach.  Too bad that Metafont doesn't 
> have MetaPost's |cutafter| and |cutbefore| macros.

What are these doing ? There names seem to indicate that they are automating
what I have done manually.

> > This turned out to be a bit tricky. We cannot guarantee uniform
> > spacing between the dots without sacrificing device-independence,
> > so I increased the space between the dots a bit, making the 
> > nonuniformity much less prominent. This is only a problem for
> > low resolutions, it was quite noticeable at 300dpi, but invisible
> > at 900dpi.
> 
> OK, as I see that you've used 6 dots per 12u, which makes 9 dots 
> per 18u, of which 3 dots would be deleted in the gapped versions.
> Sounds reasonable.  Remaining question:  Is it the right approach 
> to have dotted arrows rather than dashed ones in the first place?

Yes I think that is how I derived the original widths and dot separations.
About the dash/dot question: IIRC, I have taken them from Alan Jeffreys
paper about requirements for arrows. I don't know why he didn't have
dashed arrows.

> > I was surprised by the difference between the mf programs for the
> > brackets and floors in punct.mf and symbol.mf. While the brackets 
> > are very sophisticated, the floors are almost trivial. Is this
> > because the brackets are designed for text fonts, while the floors
> > are not ?
> 
> I suppose so.  Maybe we should leave the text brackets alone and
> design new math brackets based on the design of floors/ceilings.

Good idea. Should I give them rounded corners (like the floors/ceilings)
or should I change the floors/ceilings to have sharp corners ?

> P.S.  At the moment I have a couple of projects in the pipeline, 
> none of which is ready for distribution yet, but the following
> is upcoming.  Please don't rush the next release.

On my list of changes for the next version are

* Reshuffling of the extensible fonts to remove the extensible
  recipes from the variable area (an idea found in the archives)

* Made `all bigops should have small counterparts, but not necessarily
  vice versa' true (also from the archives).

* Most new bigops in MX2 now have glyphs in the cm version (their
  design is improvable though).

* Various bugs fixed. 

None of these is really urgent, so I'll wait for your stuff. 

Regards, Matthias

PS Yesterday evening I noticed that the xta family doesn't pick up
any italic glyphs from psyro. That is another point to fix before
the next version.

PPS Now that Michael Downes announced the alpha version of `breqn.sty'
should we try to make `newmath.sty' compatible with it ? From my
short look at breqn.sty, I think we would just need to provide
a command \DeclareMathCompound and use it for everything that is 
not a simple \mathchardef. 

Another point I want to investigate in the near future is how much
of AMSLaTeX math works unchanged (from experiments I did long ago,
I remember that \sqrt was problematic, since it assumes OMS/OMX encoding).