Georg Baum <[EMAIL PROTECTED]> writes:
| Am Samstag, 21. Oktober 2006 19:36 schrieb Lars Gullik Bjønnes:
| > Discussions are made and concluded in the kitchen, those not able to
| > get out of the living room get no say.
| > Espeically not if they does not help with providing solutions instead
| > of problems.
|
| Why should we provide a solution when you tell us several times to ignore
| latex limitations and it is announced that no solution will be
| allowed?
We should ignore latex limitations in the core. All latex specific
handling should be done on output.
| You should know both Jürgen and me well enough to understand that we are
| not going to simply demand solutions without helping to find it.
So far no solutions has been proposed.
(Except the one below and the one that we put in.)
| For information I attach here the patch I was working on yesterday before
| the freeze announcement. It already works for the case where you have only
| one encoding in the document. I also had an idea how to treat multiple
| encodings that would need a similar amount of changes. Then you would need
| to add an utf8 encoding to the list (and all the numbers in lib/encoding
| can probably be removed), some error handling for the case where iconv
| fails, and then you can use every encoding you could use in 1.4 + utf8.
A native tex encoding would be great. Then we would not need to handle
inputenc at all, just provide the correct packages to get access to
fonts and char commands.
I fear that doing the explicit
encodings as below we are only able to export a very small subset of
what lyx can show on screen (and store internally)
| Index: src/encoding.h
| ===================================================================
| --- src/encoding.h (Revision 15452)
| +++ src/encoding.h (Arbeitskopie)
| @@ -29,8 +29,9 @@ public:
[...]
I am not quite sure that I like the generalization of the utf8 facet,
perhaps creating a base facet and explicit facets for the other
encodings would be better.
--
Lgb
