LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Sun, 2 Jan 2011 11:55:48 +0000
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID: <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <20110101230758.GA15697@khaled-laptop>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
From: Joseph Wright <[log in to unmask]>
Parts/Attachments: text/plain (51 lines)
On 01/01/2011 23:07, Khaled Hosny wrote:
> Even for "western European languages" Unicode and smart fonts (both not
> supported "natively" pdftex) have been the norm for decades now; 8bit
> encodings and type1 fonts are obsolete and almost nobody outside tex
> community is using them. There is a growing body of fonts, for example,
> that can not be used with pdftex without pre-processing, if at all. The
> fact that pdftex can do some jobs is just keeping with the status quo
> and not moving forward, IMO. I think a new system like latex3 can be a
> good opportunity to get rid of legacy craft that tex have been carrying
> around over the year; no need to keep supporting it (when every one else
> is moving away from it) tell the eternity.

There are a *lot* of documents created using LaTeX2e which do not need 
to go beyond what pdfTeX can do, so there are two sides to this. How you 
see the balance probably depends on your personal position.

Now, speaking personally I also see the point of accepting that things 
move on (it would make life a lot easier in some areas). However, 
LaTeX2e has been successful partly because of the caution the Project 
has always applied to making changes. So any change in engine support 
will need to be backed up by good reasons, not simply 'it seems like a 
good idea' without any clear code to back this up.

(On the 'support to eternity' question, there are lots of people who 
won't even use LaTeX2e because 'it is not stable enough'. So again there 
is a balance here.)

>> As I said earlier, we decided to require \pdfstrcmp after some
>> applications came up where the alternatives were a bad idea
>> (difference in expandability with different supported engines). So
>> this might change as we develop more code. I can only comment on
>> what we have now, where there is no strong case for dropping support
>> for pdfTeX. (Indeed, almost all of the day-to-day testing I do uses
>> pdfTeX as it remains my default engine. LuaTeX is a lot slower, I'm
>> afraid, quite apart from questions about bugs introduced by the
>> ongoing changes.)
> I'd be interested to know more about this slowness, my own tests shows
> that luatex 0.60 is just 1.3 to 1.6 as slower as pdftex, not that
> significant IMO, and that is testing with "stock" format, code written
> to take advantage of luatex features can be much faster than comparable
> pdftex code (in context, for example, certain operations are done tens
> of times faster in luatex than in pdftex).

I see quite a lot of 'start up' time with LuaTeX, but have never done 
any formal testing. The start up time is important to me as most of my 
test documents are rather short, so the start up is a large chunk of the 
total. Things might well be different with larger documents.
Joseph Wright