LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Date:
Mon, 5 Feb 2001 12:41:56 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (112 lines)
Frank, Chris,

I must admit that I'm too critic with my own macros and that
I try to study every possible implication of them, even if
finally they are unimportant.

>  > However, I found several problems. For example:
>  > - if I say \fontencoding{T1,OT1} we will get t1cmr which points to
another
>  >   font (ec) and not to a t1 encoded cmr,
>
> perhaps we should have that as a separate debate, but the ec fonts where
> supposed to be extended cmr at least this is what they started out to be.
I
> know that Joerg in the end did one or the other change but at least the
> original intention was that those fonts should have been indistinguishable
on
> their common subset of glyphs (and this is why in LaTeX they are
considered
> both family cm).
>
> if a lot of people think this is not the case then this opens an important
> discussion about what to do with them, but it doesn't seem to me a
criticism
> or a problem with the general approach taken in my sample code.

Actually, this is not a criticism to this approach, just an issue. While
there are free PostScript ot1cmr fonts, there are only MF t1cmr ones, which
to me is a huge difference. Sometimes I combine Palatino (T1) and cmtt
(OT1),
and \selectfont{T1,OT1} is not enough. The solution I took in my macros was
to allow explicit declarations like:
  \SetFontEnconding{cmtt}{OT1}

>  > - more importantly, we lost the control of the final result, because
>  >   a faked accented letter may be not exactly the same as an actual
composite
>  >   letter. It so happens that no TeX installations are the same and
perhaps
>  >   a different font in selected in another system just because a file
has not
>  >   been installed.
>
> but this is true already, isn't it? as of today a formatting of latex
document
> depends on a number of factors, one of which is the available fonts. so
100%
> output compatibility is only achieved if you
>
>  - have an identical set of fd files
>  - have identical metrics (this was especially with PostScript fonts an
issue
>    in the past)
>  - actually have the fonts installed that the fd files and metrics are
>    pointing to.

But TeX complains, except in the case of locally generated metrics.
One of the solutions I considered was to generate a file recording the
decisions taken in a system when a document is typeset, so that if we
really want to ensure that TeX complains if there is a different
configuration we can distribute that file with the main .tex ones.
And after all if we really really want a certain layout the obvius
solution is to distribute only a pdf file...

> [Chris]-- differences in the metrics (these can cause major differences in
> the typesetting).

Yes, differences in the metrics, which can reshape the whole document.

> if I now write a document and specify \fontencoding{T1} it might not run
at
> all at a site not having T1 fonts (though such a site is in theory not
allowed
> to exist) or it might switch to ec as default fonts, while with a range of
> encodings i would get a result "closer" to the intended output.
>
>
> also please note that my code (after your fix:-) does both: you can still
> specify a single encoding and then only that encoding will get used ie you
get
> the situation as it is now where the user has total control (assuming that
fd
> files are the same).
>
>  > Despite that, I think that is the right way, and I'm studying how to
solve
>  > these issues. Any ideas?
>
> do you have any other issues than the two above? you mentioned them as
"for
> example".

There are in part related to the fact that a language or a script
can provide a set of default encogings. (Note: in the current draft
for Lambda there are files for both languages and scripts).
But I think that:

> also please note that my code (after your fix:-) does both: you can still
> specify a single encoding and then only that encoding will get used ie you
get
> the situation as it is now where the user has total control (assuming that
fd
> files are the same).

is the best solution.

Cheers
Javier

______________________________________________________________________________
Consigue tu cuenta de correo universal y gratuita en http://webmail.wanadoo.es

ATOM RSS1 RSS2