Re: [pdftex] Re: .svg and pdflatex
At 10:30 AM 11/28/2002 +0100, Tobias Haustein wrote: Martin Schroeder wrote: Noone has reported about this yet. You would need to convert the .svg to something pdfTeX can handle, i.e. Metapost, pdf, jpeg or png. Metapost should be possible. pdf seems doable if you use an svg parser and a pdf lib. I don't know of such a solution. SVG is a lot more powerful than PDF since it allows filter effects and animation. The other advanced features of SVG can be emulated with more or less effort. The filter effects can be approximated but you need to define a resolution to do them. Therefore, you loose the vector properties of SVG. An SVG to PDF converter that ignores filter effects and animation shouldn't be too hard to write. We've discussed this and decided to write a PDF parser instead. Our graphics library is then used to render the parsed graphic primitives in order to generate either PDF, SVG, Flash (SWF) or raster graphics (GIF, PNG, JPG, TIFF). Since there are SVG parsers readily available (e.g. Batik from the Apache project), such a converter shouldn't be too hard. Since there are svg viewers, why not write a plugin into acrobat? [unfortunately, the movie plugin does not not support the quite powerful applescripting which is part of the movie spec] Hans - Hans Hagen | PRAGMA ADE | [EMAIL PROTECTED] Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com - information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -
Re: finally: new texmf tarball (beta-20011128)
Hi Thomas, I hope that you're on schedule with the thesis etc. But I admit that it is a bit difficult (Hans Hagen changed the ISP and was not yet able to move the DNS over to the new provider). The official Yes, I have downloaded from the wrong site. Oh, if only CTAN was really *comprehensive*... page is: http://ds035.xs4all.nl/download.htm Ok, I just fetched that version. Now, I see that Context tries to be clever and introduces a new scheme of loading fonts for pdftex: type-map.tex. What's that good for? Why does Context think that it knows better which fonts to load than the pdftex configuration? I assume that you refer to the map loading? There are several reasons for the current context font scheme: (1) i want to users to *use* the fonts that are in the distributions and i was surprised that many of them failed to do so due to all kind of encoding problems (2) the current font naming scheme is a real pain if someone adds commercial fonts, so for those cases i use encoding-original nameng schemes (more verbose, like on xwindows) (3) when one generates instances, say a slanted one, there can be conflicts in metrics with already available ones, and since pdftex only sees the first definition of a font in the map file (4) pdftex uses the map file info for decising how to handle fonts in included pdf graphics; this can lead to pretty nasty conflicts when the same font is used in different disguises; this is one reason for omitting the second entry (full name) in the map file. (5) I don't expect users to manipulate map files, so i generate them and load them on demand (it would be nice if one could use difefrent pdftex.cfg's depending on the format) (6) in context it is now possible to use pretty complex combinations of fonts with a minimum of commands (sometimes we have a document in say lucida with inserts in times and this means that we need to manage fonts in namespaces, can have the same fonts in different encodings, etc etc; you cannot imagine what designers can come up with). (7) when using tex in a workflow, with commercial fonts, and still a clean way to upgrade available, a dedicated font tree is quite handy, so i recommend context users to use texmf-fonts for their own fonts and this is supported by texfont.pl (8) whan thanh is on line agan (in a couple of months) he will look into the map file mess; currently pdftex only loads font map files at the first page, but we need the possibility to define fonts halfway the document; also, currently entries cannot be overloaded, so once there is a undesired entry in the main map file, there is no way to replace it, apart from editing the map file. (9) a handicap is that there is no clear way to control where map files are looked for; it would help in in texmf.cnf there would be a way to specify a map path for context. btw, context can still happily use all the existing stuff - Hans Hagen | PRAGMA ADE | [EMAIL PROTECTED] Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com -
Re: ConTeXt formats
At 07:24 PM 9/20/00 -0300, George White wrote:
On Wed, 20 Sep 2000, Hans Hagen wrote:
Appearances will suffer if you just do a straight replacement of lbr with
cmr or pos.
The problem is that the user doesn't get helpful feedback if they try to
use lbr under the impression that it should work. It would be better if
the system can be organized so that anyone who trys the presentation
styles or the pdftex manual and doesn't have Lucida fonts will get a
helpful explanation at the earliest possible stage.
This is a difficult problem. On todays systems messages are shown so fast
that no one sees them.
The main problem in logging fonts is that there is no quick way to
determine if a font is available. I looked into this some time ago, but
file searching sort of interferes here.
The "missing commercial fonts" problem occurs quite frequently with LaTeX,
and is going to get messier as more people try to use Belleek, LucidaSO,
or other free, but more limited, substitutes for commercial font packages
(since users will encounter documents that were generated without error
but don't display as expected).
I recently found out that there have been changes in low level tex code
with regards to reporting font names in overfull boxes. quite annoying btw
such a change, since i used to catch it and assumed that it was frozen tex
code -)
Updmap could warn of missing font files as it processes the maps, but
there is still a big difference between TeX and pdfTeX. Some people
happily create .dvi files that use fonts they don't have, and switch to a
system that has the fonts when they need hardcopy. Maybe updmap can have
a flag that controls whether the generated map files can refer to missing
fonts.
Rather than the current "invisible" substitutions that are used for
Belleek, the substitutions be made "explicit" as in
\usepackage[belleek]{mathtime}.
In my experience, many ConTeXt early adopters do have both table.tex and
the Lucida fonts from YY, so new users and users new to teTeX both stand
a good chance of encountering documents that use these.
There was posting on the context list on free lucida's which i have to look
into.
I can think of a method where users have to enable specific font support,
but that would mean that context will not be upward compatible which is bad.
We may consider the following: patch web2c so that \font\somefont=somename
does not report an error, but sets the font to nullfont so that we can
check on it. An alternative is: \openin18=filename to open any file known
to kpse and let \ifeof be used to determine its existence. But, it's more
complicated, since many tex's have lbr.tfm but lack lbr.pfb or used a
mapped version. So, another approach would be:
\immediate\write18{locatefont: filename logfile}
and report back info about available pfb/pk's to tfm files. This is not so
much different from pdftex calling mf to generate fonts but not portable
among tex's. I'll give it a thought.
Maybe I should provide a utility that auto maps fonts. Not that complicated
i think. I'll give it a thought too, since it seems a clean solution.
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-
