Hi, I occasionally run into (commercial) fonts that have gaps in their encoding vector. For instance, no 'sfthyphen', or no fi/fl/ffl/ffi ligatures. Of course one can handcraft a vector, but to keep thinsg simple I wonder how complicated it would be to have a fall back, say: - if no sfthyphen is present, then take the hyphen - if no fi ligature is present, output an f and i and cross your fingers for proper font based kerning If you look into the texnansi vector, yuo will notice that esp this sfthyphen has resulted in either taking or not taking a slot. Of course another option could be to patch afmtotfm to do a more rigourous check (remove ligs that are not in the font, remap sfthyphen). Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl 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 -------------------------------------------------------------------------
Hi Hans, can you be please more specific? Do you use those fonts with tex, or they are included in some pdf figure? If you want to use them in the ``standard'' way, then the way to make it work properly is to use fontinst. Fontinst is itself complicated and hard to use as (plain) tex, but so far it is the most flexible way (IMHO) to do that. Thanh On Wed, Feb 04, 2004 at 05:41:21PM +0100, Hans Hagen wrote:
Hi,
I occasionally run into (commercial) fonts that have gaps in their encoding vector. For instance, no 'sfthyphen', or no fi/fl/ffl/ffi ligatures. Of course one can handcraft a vector, but to keep thinsg simple I wonder how complicated it would be to have a fall back, say:
- if no sfthyphen is present, then take the hyphen - if no fi ligature is present, output an f and i and cross your fingers for proper font based kerning
If you look into the texnansi vector, yuo will notice that esp this sfthyphen has resulted in either taking or not taking a slot.
Of course another option could be to patch afmtotfm to do a more rigourous check (remove ligs that are not in the font, remap sfthyphen).
Hans
Hi Thanh,
can you be please more specific? Do you use those fonts with tex, or they are included in some pdf figure?
with tex
If you want to use them in the ``standard'' way, then the way to make it work properly is to use fontinst. Fontinst is itself complicated and hard to use as (plain) tex, but so far it is the most flexible way (IMHO) to do that.
i never use fontinst, just afm2tfm and alike (open type or ttf tools and so) so maybe afm2tfm and ttf2tfm need to become more clever; the problem is that some (commercial) fonts lack he f* ligatures and the softhyphen, and i don't want to end up in either special encoding vectors (well, maybe i should) or whatever setup is needed for fontsinst. this brings me to a another feature request: a switch to turn off ligature building, this is for instance needed when one is processing xml documents, where --- means three dashes and not a ligature, i guess that you can implement that switch with your eyes closed -) Hans
Hi, changing pdftex_fail() --> pdftex_warn() when a config file is not found caused pdftex to segfault when pdftex.cfg is not available. I fixed it but not submitted yet. Just want to announce it so we don't duplicate the work. Thanh
Hi, I am going to review the avl patch by Hartmut and merge it to pdftex sources. So if anyone is considering to do that, please let me know so we don't do the same thing twice. Thanh
Hi, a few parameters have been added to config file: pdf12compliantcode pdf13compliantcode pdfminorversioncode alwaysusepdfpageboxcode pdfoptionpdfinclusionerrorlevel I wonder whether we have to change a few of them; as pdf12compliantcode pdf13compliantcode are here, then we probably have to do the same thing for pdf1.4, pdf1.5 and so on. And when we get to pdf2.0, we will have to have something like pdfmajorversioncode. So if not too many people are depending on those above features, I am going to reimplement them. Please let me know your opinions. Regards, Thanh
On 2004-02-13 11:55:01 +0100, The Thanh Han wrote:
pdf12compliantcode
Leftover from before pdfminorversioncode. Obsolete.
pdf13compliantcode
Extension of pdf12compliantcode :-)
pdfminorversioncode
We need something like this. And an integer parameter was much easier to implement than a real parameter.
alwaysusepdfpageboxcode
ArtCom needs this for compliance with earlier pdfTeX versions which always used the /MediaBox for included pdfs.
pdfoptionpdfinclusionerrorlevel
Needed. But could probably be better named. [...]
and so on. And when we get to pdf2.0, we will have to have something like pdfmajorversioncode.
2.0 will need a new _very_ major version of pdfTeX, as major version increments of pdf will break every pdf consuming application. Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
At 11:55 13/02/2004, The Thanh Han wrote:
Hi,
a few parameters have been added to config file:
pdf12compliantcode pdf13compliantcode pdfminorversioncode alwaysusepdfpageboxcode pdfoptionpdfinclusionerrorlevel
adding options is ok as long as they can also be set from within pdftex itself
I wonder whether we have to change a few of them; as
pdf12compliantcode pdf13compliantcode
are here, then we probably have to do the same thing for pdf1.4, pdf1.5 and so on. And when we get to pdf2.0, we will have to have something like pdfmajorversioncode.
So if not too many people are depending on those above features, I am going to reimplement them. Please let me know your opinions.
pdfmajorversioncode pdfminorversioncode sound ok to me (these are reflected in the %PDF1.4 line as well as the (ne win pdf 1.5) /Version key !) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE/POD/CTS 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 -------------------------------------------------------------------------
participants (3)
-
Hans Hagen -
Martin Schröder -
The Thanh Han