metapost a svg

I have only now realized, that svg output of mp gives about 80% 
scaling of the picture (checking the dimensions of unitsquare in 
inkscape and the resulting eps output). Is it a bug or feature?-)

Karel Horak
--
http://tug.org/metapost/

Re: metapost a svg

On 10/01/2010 09:58 AM, Karel wrote:
>
> I have only now realized, that svg output of mp gives about 80% scaling
> of the picture (checking the dimensions of unitsquare in inkscape and
> the resulting eps output). Is it a bug or feature?-)

That is definitely not intentional, but it may be unavoidable. There
are lots of small compatibility issues with the use of viewPort, and
this could be one of them.

Best wishes,
Taco
--
http://tug.org/metapost/

Re: metapost a svg

Dne 1.10.2010 8:05, luigi scarso napsal(a):
>>
> Do you have a short example ?
>

I have attached an easy example, but looking into xml code of the 
svg output, it is now clear, that mpost has written the same data 
into both outputs, so the reason should be looked for in inkscape 
and its translating of "viewbox".

Karel

outputformat := "svg";
outputtemplate := "sq1.svg";
% filenametemplate "31-2.eps";
%===========================
beginfig(1);
draw unitsquare scaled 25mm;
endfig;

end.

--
http://tug.org/metapost/

Re: metapost a svg

I have found the reason for difference:
mpost uses points, but inkscape reads in the numbers as px. I have 
no experience with this unit, but found that the ratio px/pt 
corresponds exactly to my previous observation.

karel
--
http://tug.org/metapost/

Re: metapost a svg

At 05:16 AM 10/1/2010, you wrote:
>I have found the reason for difference:
>mpost uses points, but inkscape reads in the numbers as px. I have 
>no experience with this unit, but found that the ratio px/pt 
>corresponds exactly to my previous observation.

"px" usually means "pixel". This, of course, is resolution dependent.
I recall I used to have a lot of problems with some bitmap to ps
conversion programs, until I learned how to use their resolution
options. The default always seemed to be 1 pixel = 1 point. It is
also the case that PDF assumes 72 pixels to the inch unless
otherwise informed.

Typical screens have about 80-100 pixels to the inch (96 on
the one in front of me now), so 72 pixels would be 80% of an
inch, more or less.

Dan

Daniel H. Luecking
Department of Mathematical Sciences
Fayetteville, Arkansas
http://www-cs-faculty.stanford.edu/~knuth/iaq.html 

--
http://tug.org/metapost/

problem with 'dvips mproof'

Hi,

when processing a file s.mp containing the lines

prologues := 3;
beginfig(1);
   label("test", origin);
endfig;
end

as

   mpost s
   tex mproof s.1
   dvips mproof

I have difficulties watching the resulting file mproof.ps in GSview or 
PS_View (remember, this is dvips output).  Symptoms are different for 
different values of variable prologues.

PS_View

   0   -   The files looks fine with text "test" probably rendered in
           CMR.

   1   -   Fine again.  But at closer inspection the kerning between
           letters changes slightly in comparison to prologues:=0.

   2   -   Exactly the same as with prologues:=1.

Re: problem with 'dvips mproof'

On 9 October 2010 Stephan Hennig wrote:

 > Hi,
 > 
 > when processing a file s.mp containing the lines
 > 
 > prologues := 3;
 > beginfig(1);
 >    label("test", origin);
 > endfig;
 > end
 > 
 > as
 > 
 >    mpost s
 >    tex mproof s.1
 >    dvips mproof
 > 
 > I have difficulties watching the resulting file mproof.ps in GSview or 
 > PS_View (remember, this is dvips output).  Symptoms are different for 
 > different values of variable prologues.
 > 
 > 
 > PS_View
 > 
 >    0   -   The files looks fine with text "test" probably rendered in
 >            CMR.
 > 
 >    1   -   Fine again.  But at closer inspection the kerning between
 >            letters changes slightly in comparison to prologues:=0.

Re: problem with 'dvips mproof'

Am 10.10.2010 02:52, schrieb Reinhard Kotucha:
> On 9 October 2010 Stephan Hennig wrote:
>
>> 0   -   The files looks fine with text "test" probably rendered in
>> CMR.
>>
>> 1   -   Fine again.  But at closer inspection the kerning between
>> letters changes slightly in comparison to prologues:=0.
>>
>> 2   -   Exactly the same as with prologues:=1.
>>
>> 3   -   The text is visible, but rendered with something else than
>> CMR (probably Courier).
>
> [quotes reordered]
>
> BTW, the prologues variable might be confusing because you have to
> remember what all the values are good for.  But it's probably
> helpful to know that Metapost was designed to support dvips in the
> first place, hence you don't have to set prologues at all for dvips.

My understanding up until now was like your (possibly unintentional)
conclusion in the last sentence: you don't have to set prologues to
values >0 for dvips, but it doesn't hurt to do so.  I'm seldom using
dvips, but prefer pdftex, where prologues is much less relevant, but do 
I understand you correctly that setting prologues to 0 is /mandatory/ 
when using dvips or dvipdfm as a post-processor for MetaPost files?

> With prologues>  0 metapost creates (more or less) standalone
> PostScript files.  Standalone means that either the font is embedded

Re: problem with 'dvips mproof'

On 10/10/2010 12:26 PM, Stephan Hennig wrote:
>>
>> BTW, the prologues variable might be confusing because you have to
>> remember what all the values are good for. But it's probably
>> helpful to know that Metapost was designed to support dvips in the
>> first place, hence you don't have to set prologues at all for dvips.
>
> My understanding up until now was like your (possibly unintentional)
> conclusion in the last sentence: you don't have to set prologues to
> values >0 for dvips, but it doesn't hurt to do so. I'm seldom using
> dvips, but prefer pdftex, where prologues is much less relevant, but do
> I understand you correctly that setting prologues to 0 is /mandatory/
> when using dvips or dvipdfm as a post-processor for MetaPost files?

Apparently. The problem is that dvips subsets its own fonts without
adding a proper subset prefix to the font name, so that the embedded
font that results from prologues:=3 is actually not used.

(almost) All PostScript type1 fonts begin with a bit of special
PostScript that attempts to reuse an already defined font by the
same name, to preserve printer memory.

This works just fine if the predefined name is in fact the full
font, but it fails if (as is the case of dvips) the predefined
font is actually a subset of the font (in this particluar case only
the page number, '1', is included). This is also why Adobe is recommends
adding a subset prefix to subsetted fonts. But dvips does not do that,
even though Metapost does: that is why the font in s.1 is named
"ORMKKB-CMR10" instead of just "CMR10".

Re: problem with 'dvips mproof'

Am 10.10.2010 17:32, schrieb Taco Hoekwater:
> On 10/10/2010 12:26 PM, Stephan Hennig wrote:
>>>
>> [...], but do I understand you correctly that setting prologues to
>> 0 is /mandatory/ when using dvips or dvipdfm as a post-processor
>> for MetaPost files?
>
> Apparently. The problem is that dvips subsets its own fonts without
> adding a proper subset prefix to the font name, so that the embedded
> font that results from prologues:=3 is actually not used.
>
 > [...]
>
> So, the cause of the problem is a flaw in dvips.

Thanks!  I have moved the issue to tex-k.

Best regards,
Stephan Hennig
--
http://tug.org/metapost/