headers
Stephan Hennig | 1 Mar 2008 10:48
Picon
Favicon

Re: mpman: title page

Karl Berry schrieb:

> P.S. \logo was undefined in last night's run of mpman.tex.  Didn't check
> if it's already been fixed, sorry ...

I've replaced the manual definitions by package mflogo that defines \MF
and \MP for the logos.  As a side effect more logo fonts are now used in
the manual, presumably more different optical sizes (which is not wrong,
IMHO).

Best regards,
Stephan Hennig

--
http://tug.org/metapost/
Permalink | Reply | 2 comments |
headers
Taco Hoekwater | 1 Mar 2008 11:14
Gravatar

Re: mpman: title page


Hi,

Stephan Hennig wrote:
> Karl Berry schrieb:
> 
>> P.S. \logo was undefined in last night's run of mpman.tex.  Didn't check
>> if it's already been fixed, sorry ...
> 
> I've replaced the manual definitions by package mflogo that defines \MF
> and \MP for the logos.  As a side effect more logo fonts are now used in
> the manual, presumably more different optical sizes (which is not wrong,
> IMHO).

Like Karl, I would have been just as happy with

   \def\MF{Metafont}
   \def\MP{MetaPost} % not used, I know

and done away with the somewhat distracting logo font switches. That
we happen to have a font containing only AEFMNOPST does not mean that
this font should therefore be used for names consisting of AEFMNOPST.

In the Maps journal I suppress all such 'typographic logo effects'
except for the lowered E in Knuth's \TeX macro, because they are
distracting to the reader and generally make typeset material look
like high school papers.

Just my 2c,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dirk Laurie | 3 Mar 2008 08:16
Picon
Picon
Favicon

Re: mpman: title page

Taco Hoekwater skryf:
> That we happen to have a font containing only AEFMNOPST does not mean 
> that this font should therefore be used for names consisting of AEFMNOPST.
> 
The letters P and S were added to the original seven letters by Donald 
Knuth himself so that it would be possible to typeset METAPOST in that 
font.  That particular name is therefore in a unique position.

> In the Maps journal I suppress all such 'typographic logo effects'
> except for the lowered E in Knuth's \TeX macro, because they are
> distracting to the reader and generally make typeset material look
> like high school papers.
>
Others may say that using capital letters in the middle of a word
makes typeset material look like source code written by someone who
has read too many C++ or Java style guides.

It's a matter of taste.  Let's not be prescriptive about this.

Dirk
--
http://tug.org/metapost/
Permalink | Reply | 0 comments |
headers
Giuseppe Bilotta | 5 Mar 2008 08:43
Picon

Ohloh.net

Hello all,

I took the liberty to submit MetaPost as a project to
Ohloh.net, the open source project analysis site.

http://www.ohloh.net/projects/12535

I'm sure I might have gotten something wrong, so feel free
to correct all the project information as appropriate.

--

-- 
Giuseppe "Oblomov" Bilotta

--
http://tug.org/metapost/
Permalink | Reply | 0 comments |
headers
Stephan Hennig | 10 Mar 2008 02:11
Picon
Favicon

Re: mpman: title page

Taco Hoekwater schrieb:

> It makes more sense to do something with the svn:date tag (I assume
> there is an svn package on ctan?). I've set up the manual tex files
> to do Id and Date substitution, but you have to add something like

I've added Subversion support via the svninfo package.  The check-in
date can be accessed via \svnToday.  It would be nice if someone could
revise the title page adding the logo before the next release, i.e.,
before Easter.

Best regards,
Stephan Hennig

--
http://tug.org/metapost/
Permalink | Reply | 6 comments |
headers
Troy Henderson | 10 Mar 2008 12:44
Picon

Re: mpman: title page

Do we intend to keep the abstract on the title page?  I have no real
opinion here, I just want to get everyone else's before I make any
changes.

Troy
--
http://tug.org/metapost/
Permalink | Reply | 5 comments |
headers
Taco Hoekwater | 10 Mar 2008 13:07
Gravatar

Re: mpman: title page

Troy Henderson wrote:
> Do we intend to keep the abstract on the title page?  I have no real
> opinion here, I just want to get everyone else's before I make any
> changes.

I wouldn't. The original by JDH was a technical report (CSTR 162), but
the manual is steadily getting longer and becoming more book-like.

Best wishes,
Taco

--
http://tug.org/metapost/
Permalink | Reply | 3 comments |
headers
Troy Henderson | 10 Mar 2008 13:34
Picon

Re: mpman: title page

>  I wouldn't. The original by JDH was a technical report (CSTR 162), but
>  the manual is steadily getting longer and becoming more book-like.

For that matter then, should we even have the abstract?

Troy
--
http://tug.org/metapost/
Permalink | Reply | 2 comments |
headers
Stephan Hennig | 10 Mar 2008 14:13
Picon
Favicon

Re: mpman: title page

Troy Henderson schrieb:
> Do we intend to keep the abstract on the title page?

No opinion to /that/ question.  But what are the alternatives?  Putting
it onto the next page before the toc looks really strange and I can't
remember having seen anything like that before.  Another option would be
to put it on its own page.  I guess, as long as we don't have a fancy
title page with nice graphics the abstract is best placed there.  We can
try to make it sound more interesting to new users, though.  (That
applies to the whole first section, too.)  Contributions are always welcome!

Best regards,
Stephan Hennig
--
http://tug.org/metapost/
Permalink | Reply | 0 comments |
headers
Stephan Hennig | 11 Mar 2008 18:14
Picon
Favicon

Re: [mp-implementors] Metapost 1.003 release candidate

[CC to metapost list where presumably more people are subscribed.]

Taco Hoekwater schrieb:
> 
> Stephan Hennig wrote:
>> Taco Hoekwater schrieb:
>>> Stephan Hennig wrote:
>>>> See the thread "[metapost] problem with drawoptions and fake Euro
>>>> symbol" from 2007-11-13.  Here's an example:
>>> Can you try this? Should work ...
>>>
>>>    def label = addto currentpicture also thelabel enddef;
>> 
>> Yes, it works.  Is this the intended fix for MetaPost?  Or is it only
>> meant as a workaround for me?  I'd appreciate the former, since the
>> current behaviour is not compliance with this statement from the manual:
> 
> I am not sure whether the manual was wrong or the implementation.

In the thread mentioned above I have seen some support for the latter
option (see Dan's and Hartmut's mails).

> The current definition of label has been there for a long time:
> 
>    def label = draw thelabel enddef;
> 
> If the manual is correct, this is a fix that should go into 1.003,
> but if the manual is wrong, this is for you only: changing label
> would break backward compatibility in that case.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane