Jesús Guillermo Andrade | 14 Apr 21:19 2009
Picon

Embedding fonts in graphics

Dear fellows: I've been trying fruitlessly to embed fonts into a metapost graphic and I keep getting the same result: a courier like font in the final eps.
What is wrong with this?: 

% Preparacion
prologues:=3;
filenametemplate "%j-%3c.eps";
fontmapfile "pdftex_dl14.map";
input mp-tool;
input mp-spec;
u=1cm;

...

% Right part of heading for letters...  
  path linea;
  linea = (9.15u,-1.4u)--(9.15u,1.3u);
  draw linea withpen pencircle scaled 2.1;
% Text
  defaultscale := 12pt/fontsize(defaultfont);
  margen := 95u;
  defaultfont := "fvsr8r";
  draw "Andrade & Moreno S.C." infont "ec-lmr10" shifted (0u,3.2u) scaled defaultscale;
  draw "A&M Despacho de Abogados" infont "fvsr8r" shifted (1u,2.2u) scaled defaultscale;
  pickup pencircle scaled 2bp;

Results:

Is possible that this could be a problem with the names of the font? Is there a way  to produce sample pdf with examples of all fonts installed in  my system?

Thanks a lot! 


Si los hechos no se ajustan a la teoría, deben ser desechados. Ley de Maier.
------------------------------
Jesús Guillermo Andrade (Abg.)
Gerente de Litigios y Corporativo. EDM. AC. API.
Andrade & Moreno S.C. (http://amlegal.wordpress.com/)

Attachment (amhead-001.eps): application/postscript, 43 KiB
--
http://tug.org/metapost/
Taco Hoekwater | 14 Apr 22:32 2009

Re: Embedding fonts in graphics

Jesús Guillermo Andrade wrote:
> Dear fellows: I've been trying fruitlessly to embed fonts into a metapost 
> graphic and I keep getting the same result: a courier like font in the final eps.
> What is wrong with this?: 

mp-tool resets prologues to 1, so you have to move the prologues:=3
statement a few lines down.

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

Troy Henderson | 18 Apr 15:59 2009
Picon

TeXworks + MetaPost

I have had quite a few people recently asking about a standalone version of my MetaPost Previewer which incidently located at

http://www.tlhiv.org/mppreview

and counters indicate that the previewer gets about 15 hits or so each day.  This lets me know that the number of people using it is at least moderate.  I believe that the primary reason for this is for the same reason that TeXshop and TeXworks have become so popular, i.e., they have lowered the entry barrier for TeX.  I know that the intricacies of MetaPost were quite daunting for me in the beginning, especially subtleties of things like output file naming schemes and font inclusion. I've recently started working on a standalone version using wxWidgets (similar to Qt) since wxWidgets is a cross-platform toolkit that relies on each platform's own native controls (instead of emulating them) to give the same look and feel as other applications on that platform.  However, I'm now thinking that since many of the features that I would like to provide in this standalone version are already available in TeXworks for TeX documents, it seems natural that I should perhaps focus my attention on getting TeXworks to work with MetaPost in a similar manner than it does for TeX documents.  I have no Qt experience, but it seems that getting TeXworks to support MetaPost should be a pretty easy task.

I have done quite a bit of C programming, but the main problem that I have here is that I'm not a great C++ programmer and am basically trying to learn visual programming with wxWidgets without this skill.  As a consequence, things are quite slow (as you can imagine).  The purpose of this message is to solicit expertise in helping with this venture so as to make it easier for current (but most especially future) MetaPost users to develop their figures by lowering the entry barrier.  I have ideas on 2 or 3 features that I believe are important, but I won't bother sharing them at this point.

Thoughts?

--
Troy Henderson
Assistant Professor
Department of Mathematics
University of Mobile
http://www.tlhiv.org

--
http://tug.org/metapost/
Taco Hoekwater | 18 Apr 18:20 2009

Re: [mp-implementors] TeXworks + MetaPost

Troy Henderson wrote:
>                               However, I'm now thinking that since many of
> the features that I would like to provide in this standalone version are
> already available in TeXworks for TeX documents, it seems natural that I
> should perhaps focus my attention on getting TeXworks to work with MetaPost
> in a similar manner than it does for TeX documents.  I have no Qt
> experience, but it seems that getting TeXworks to support MetaPost should be
> a pretty easy task.

I think this idea is wonderful. I know almost nothing about c++
programming, but I could definately help you with setting up a
'qt' MPlib backend that draws directly into a QPicture instead
of going through temporary files.

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

Troy Henderson | 18 Apr 20:31 2009
Picon

Re: [mp-implementors] TeXworks + MetaPost

but I could definately help you with setting up a
'qt' MPlib backend that draws directly into a QPicture instead
of going through temporary files.

I'd have to look closer at the code, but I'm pretty sure TeXworks uses Poppler to render PDF's to display in its viewer.  In fact, it would be nice to have the MP source code create a multipage PDF (one page for each MetaPost figure).  We could then encourage users to use (for LaTeX) the "pdfpages" package specifically with the \includepdf[pages={1}]{foo.pdf} (for example) command for each instance to include each graphic in the PDFLaTeX document.

Troy
--
http://tug.org/metapost/
Mojca Miklavec | 26 Apr 01:51 2009
Picon

straight lines vs. curves (SVG)

Hello Taco,

I was playing with SVG output in metapost and came accross two
questions (both with low priority):

1.) Simple code
   fill unitsquare xscaled 120 yscaled 20;
generates
   <path d="M0 20L120 20L120 0L0 0Z" style="fill:
rgb(0%,0%,0%);stroke: none;"></path>
but
    fill unitsquare xscaled 1200 yscaled 200;
generates
  <path d="M0 200C399.9939 200,800.0061 200,1200 200C1200
133.33435,1200 66.66565,1200 0C800.0061 0,399.9939 0,0 0C0 66.66565,0
133.33435,0 200Z" style="fill: rgb(0%,0%,0%);stroke: none;"></path>

What am I missing? Is there some cure to it?

2.) Since lower bits are wrong anyway: is there a simple way to limit
the number of digits that are written to file and thus reduce file
size?

Thank you,
    Mojca
--
http://tug.org/metapost/

Taco Hoekwater | 26 Apr 10:30 2009

Re: straight lines vs. curves (SVG)

Hartmut Henkel wrote:
> 
> metapost uses "in-channel signaling" for straightness by this 1/3 -- 2/3
> heuristics. And 1/3 -- 2/3 is rather "odd" due to the number 3, that 1/2
> -- 1/2 (or even 0 -- 1, why not?) for internal representation maybe
> would serve better regarding rounding.
> 
> But wouldn't it make sense to have instead a separate "straight" flag
> carried with all really straight path segments 

Yes, true. I now remember you had uploaded a patch for that, even.

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

Hartmut Henkel | 26 Apr 10:21 2009
Picon
Picon

Re: straight lines vs. curves (SVG)

On Sun, 26 Apr 2009, Taco Hoekwater wrote:

> Mojca Miklavec wrote:
> > fill unitsquare xscaled 1200 yscaled 200; generates
> >   <path d="M0 200C399.9939 200,800.0061 200,1200 200C1200
> > 133.33435,1200 66.66565,1200 0C800.0061 0,399.9939 0,0 0C0 66.66565,0
> > 133.33435,0 200Z" style="fill: rgb(0%,0%,0%);stroke: none;"></path>

> This is a faithful rendering of the internal paths:

> unitsquare is scaled to 1 pt, so the original path looked like this:
>
> (0,0)..controls (0.33333,0) and (0.66667,0)
>   ..(1,0)..controls (1,0.33333) and (1,0.66667)
>   ..(1,1)..controls (0.66667,1) and (0.33333,1)
>   ..(0,1)..controls (0,0.66667) and (0,0.33333)
>   ..cycle

metapost uses "in-channel signaling" for straightness by this 1/3 -- 2/3
heuristics. And 1/3 -- 2/3 is rather "odd" due to the number 3, that 1/2
-- 1/2 (or even 0 -- 1, why not?) for internal representation maybe
would serve better regarding rounding.

But wouldn't it make sense to have instead a separate "straight" flag
carried with all really straight path segments (point-to-point ones that
didn't get any control by the user)? Straight lines are so basic drawing
elements that maybe they should be handled as always "straight". And if
the user would get access to this flag one would still know if some line
after a few transforms was/is a really straight one.

> This is one of the areas where megapost will solve the problem
> eventually,

yes, but if it's just increasing the precision, the problem would occur
probably more seldomly (still requiring some threshold) yet in principle
stay the same (but getting even lower priority :-)

Regards, Hartmut
--
http://tug.org/metapost/

Taco Hoekwater | 26 Apr 09:09 2009

Re: straight lines vs. curves (SVG)

Mojca Miklavec wrote:
> Hello Taco,
> 
> I was playing with SVG output in metapost and came accross two
> questions (both with low priority):
> 
> 1.) Simple code
>    fill unitsquare xscaled 120 yscaled 20;
> generates
>    <path d="M0 20L120 20L120 0L0 0Z" style="fill:
> rgb(0%,0%,0%);stroke: none;"></path>
> but
>     fill unitsquare xscaled 1200 yscaled 200;
> generates
>   <path d="M0 200C399.9939 200,800.0061 200,1200 200C1200
> 133.33435,1200 66.66565,1200 0C800.0061 0,399.9939 0,0 0C0 66.66565,0
> 133.33435,0 200Z" style="fill: rgb(0%,0%,0%);stroke: none;"></path>
> 
> What am I missing? Is there some cure to it?

This is a faithful rendering of the internal paths:

(0,0)..controls (39.99939,0) and (80.00061,0)
  ..(120,0)..controls (120,6.66656) and (120,13.33344)
  ..(120,20)..controls (80.00061,20) and (39.99939,20)
  ..(0,20)..controls (0,13.33344) and (0,6.66656)
  ..cycle

and

(0,0)..controls (399.9939,0) and (800.0061,0)
  ..(1200,0)..controls (1200,66.66565) and (1200,133.33435)
  ..(1200,200)..controls (800.0061,200) and (399.9939,200)
  ..(0,200)..controls (0,133.33435) and (0,66.66565)
  ..cycle

the scale factor has brought the inaccuracies in the visible
range, but they were present already. Remember that
unitsquare is scaled to 1 pt, so the original path looked
like this:

(0,0)..controls (0.33333,0) and (0.66667,0)
  ..(1,0)..controls (1,0.33333) and (1,0.66667)
  ..(1,1)..controls (0.66667,1) and (0.33333,1)
  ..(0,1)..controls (0,0.66667) and (0,0.33333)
  ..cycle

where 0.3333 is actually 21845/65536, and 0.6667  43961/66536.

This is one of the areas where megapost will solve the problem
eventually, but until then, the solution is to use paths that
have a better original size compared to the required result, or
to use an explicit right-sized path instead of xscaled/yscaled.

> 2.) Since lower bits are wrong anyway: is there a simple way to limit
> the number of digits that are written to file and thus reduce file
> size?

No. I'll consider adding something for that, but the assumption that
the lesser digits are always wrong is not necessarily true so it would
have to be used with extreme care.

Best wishes,
Taco

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

Taco Hoekwater | 27 Apr 09:33 2009

Re: straight lines vs. curves (SVG)


Hi,

Boguslaw Jackowski wrote:
> 
> Hi,
> 
> this topic was already discussed on here a few years ago,
> but I thought that recalling some remarks would be in place.
> 
> To me, it seems convenient to represent a line segment from A to B as:
> 
>    A .. controls A and B .. B
> 
> It is easy to check the property of being a line, no additional
> flags are needed etc. The only problem is with the direction in nodes;

On the C implementation side, it is much easier&faster to check for
a straightness flag in the knot node than to check the control point
locations, so it is almost certain that the executable would not use
the pre- and postcontrol points at all for straight segments.

Best wishes,
Taco

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


Gmane