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

Re: comments on 0.59

    
>> * etx/new/mx1*.etx:
>> seems to have changed significantly compared to my version.
>> I'll have to check this more carefully, I guess.

> Yes, this may be true and if so it is due to my inability to properly
> apply your patch back in february.

What was the problem?  Should I prepare a new patch or should
I supply a new version of files?

>> * mtx/{cm,concrete/euler}/mc*hax.mtx:
>> There appear to be several changes compared to my version,
>> which I haven't checked in detail yet.  Did you miss some
>> of my patches or did you change anything yourself?
>> 
>> * tex/{cm,concrete/euler}.tex:
>> Same question as above.  Diff'ing your version against the
>> original 0.58 has fewer changes than diff'ing with my version,
>> so I wonder if there's anything I didn't that got lost?
>> 

> Yes, I had feared that some version skew might have crept in and
> that I didn't get all the changes. If in doubt, use your version.

OK, I'll see about it.

>> Other suggestions:
>> 
>> * derived/labsy[5-9].mf:
>> What about renaming them to lasyb[5-9].mf?  Otherwise MakeTeXPK
>> might produce a directory linotype/aboecklin as per fontname.

> Fine with me. I think I arrived at that name by analogy with 
> cmsy - cmbsy
> cmex - cmbex

Well, I thought that there's already an lasyb10 in the official
distribution, so why not use lasyb[5-9] as well.  As for cmbsy,
I believe the name dates back to some old truncation scheme of
using first 3 + last 3 on 6-character filesystems (on TOPS-20?).

>> Some comments on de-virtualization:
>> 
>> * Although your first attempt at organizing the files is already
>> quite good, I think it would be more useful to try to organize
>> the files by type of symbols.  In particular, 
>> 
>> - keep uc/lc Greeek letters in separate files
>> - keep all the Hebrew glyphs from cmsy + msbm together
>> - keep all the delimiters from cmr + cmsy + xma together
>> - split cmr-stuff into delimiters, punctuation, other

> Yes, but this was hacked together quickly just to see how it would
> work and to give Taco a good start on the de-virtualization. It
> certainly need more reorganization.

I'll have a look.

>> (and don't worry too much about crisp=0 in cmr and >0 in cmsy,
>> this only leads to stylistic problems such as square corners
>> in brackets but rounded in corners in floors/ceilings, which
>> we might avoid if we use the same parameters for all of them)

> It is obvious that you know more about the parametrisation of cm 
> than me.

Well, not that much actually.  Just the explanation of the parameters
from the introduction to Volume E.  AFAIK, crisp is the diameter of
serif corners.  With crisp=0 (in cmr) you get sharp corners, while
positive crisp (in cmmi) produces slghtly softer, rounded corners.

With the old setup, upright Greek capitals, \mathrm letters and 
symbols from cmr have crisp=0, while math italic Greek alphabets
have non-zero crisp and slightly lighter stems and curves.

The real question is whether this difference is really noticeable and
which choice would be more appropriate to use for an upright Greek
alphabet in the MC encoding.  Can you really see a difference between
a comma or period from cmmi or cmr?  It's the same program, after all,
but different parameters.
 
> Good idea. 

>> I might a have closer look this weekend, if I can afford some time.
>> Cheers, Ulrik.

> Thanks. I you could afford the time to create a patch containing stuff
> which I missed/misapplied would be helpful. I'm obviously not very good
> at this. Sorry for the inconvenience.

I wonder if there is a problem with sending patches directly by mail.
I've seen some patches which got messed up, for some reason, but you
should have gotten a clear warning or error mesage in such cases.

Cheers, Ulrik.