[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[eLyXer-users] Re: eLyXer 1.0.2 released

From: Alex Fernandez
Subject: [eLyXer-users] Re: eLyXer 1.0.2 released
Date: Sat, 9 Oct 2010 01:35:21 +0200

Hi again,

On Tue, Oct 5, 2010 at 4:13 AM, Uwe Stöhr <address@hidden> wrote:
> - the horizontal space in the first line is ignored in the HTML output
> - the second and third line are indented in the HTML output while they are
> not in the PDF output
> - the box, the table and the image have a width of 50 Col%. In the HTML
> output the box is much wider. The table and image are too narrow compared to
> 50 col%.
> All 3 issues arise also with LyX format 398 and as you promise to support
> format 398, these are bugs. The last 2 issues also occur with LyX 1.6.7. I
> therefore also attached the file in LyX 1.6.x's format.

As always, your issues are complex and interesting, but also hard to
fix. By the way, I found all three issues in LyX 1.6.7. They merit a
lengthy explanation:

* Horizontal space: it is ignored because it is in an ERT, and ERTs
are not supported in eLyXer. Eventually I might try to parse them, but
as you know this will open the big "LaTeX to HTML converter" can of
worms. Let me add it to the feature wish list.

* Line indentation: amusingly, this time the error seems to be in PDF
conversion. I see that from within LyX the first three lines ("x  s",
"x s" and "y") are indented, while the "z" is below and not indented.
in the PDF all lines are indented because the "z" is on the same line
as the "y" yielding "y z", and the vertical space below. eLyXer does
not intend the first line "x  s", nor the last "z", but it does intend
the second "x s" and third "y".
There remains the problem of the first line actually being indented in
the PDF and not in the HTML, but this should occur quite rarely since
documents usually have a title, front matter, TOC or similar there. I
don't think it is worth fixing, do you?

* This is made of two separate issues. The first one is the table: you
are right that it is incorrectly scaled. Here the problem is that in
LyX width is applied to the columns, which translated to HTML means
setting the width of the <td> element. It works fine for absolute
sizing of the type "2cm", but for % width it does not work at all; the
correct solution should be to add up all the % and apply the result to
the table; then go back and recompute column width from table width.
Something like this (and pardon the crude ASCII art, viewable at a
non-proportional font):
LyX (columns):   |  20col%   |  30col%   |
HTML (table):    |     20%+30% = 50%     |
HTML (columns):  |    40%    |    60%    |
This is a lot of work, and also not guaranteed to work: if one column
is 50col% and the other is 3cm, they cannot be added at all -- the
result is going to be wrong on the HTML no matter what. So I preferred
to leave % widths in tables like that, knowing that the algorithm has
some shortcomings for relative sizes. If you have a better suggestion,
or really need it to work as shown, just let me know.

* As to the image, this is intentional: upscaled images look horrible
on an HTML. eLyXer refuses to scale above the nominal resolution
(something which the PDF cannot do since it doesn't have a nominal

As you see, no easy solution for any of them.

> We now have format 401. The major new thing is support for the LaTeX-command
> \rule command via the menu Insert->Formatting->Horizontal Line.
> Maybe this feature is not trivial to implement for eLyXer.

As to format 401 and \rules: I actually tried to implement the \rule
command since it is used on the LyX Math manual, and as you know I
have tried to convert them all cleanly. I think it was around 1.0.1.
It proved too complex indeed and I wanted to release the fixes in
1.0.1, so I gave up. I have added it to the wish list and would like
to give it another try some time. But right now I have a small pile of
fixes I want to release for 1.0.3.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]