On Mon, 20 May 2024 at 15:50, Pavel Sanda <sa...@lyx.org> wrote:
> On Mon, May 20, 2024 at 03:24:30AM +0200, Thibaut Cuvelier wrote:
> > > InsetInfo shortcuts export to xhtml is borken compared to 2.3.
> > >
> > > In 2.3 we exported: <span class='info shortcut'>Ctrl+N</span>
> > > In 2.4 we expor: <bdo class="shortcut" dir="ltr">Ct+r+l+++N</bdo>
> > >
> > > Thibaut, I guess this is due to new xml routines, could you have a
> look?
> > >
> >
> > Actually, it was due to the refactoring for direction in HTML5. I have
> > pushed 7cfe36e6aa4460ae8641cd36f4aab5f013390326 and
> > e3f2b10842cdc808e9f2bf235692f283009d3734 to fix that. This could make it
> to
> > 2.4.0, as it is a bit serious.
>
> I vote for 2.4.0 as well, the fix is restricted to xhtml code which
> shows regression anyway.
> Riki?
>
> > Related issue:
> >
> > When exporting the document (User's guide) as XHTML (I haven't configured
> > LaTeX with my development LyX), I am repeatedly getting this message:
> >
> > Warning: No bibliography processor found!
> > ----------------------------------------
> > The bibliography processor requested by this document (bibtex) is not
> > available and no appropriate alternative has been
> > found. No bibliography and references will be generated.
> > Please fix your installation!
> >
> > The problem is that it appears repeatedly, meaning more than 10 times for
> > the user's guide at HEAD, apparently at each call to Inkscape to
> transform
> > SVGZ to PNG.
>
> Seems as two independent problems to me. Isn't it that you actually miss
> both svg converter and bibtex?
>
The problem is that LyX tells me there is a problem more than 10 times for
one document, 10 times the same error, with a modal window that seems to
block further processing of the document. I can just set the PATH in LyX'
configuration for these messages not to appear any longer, but they
shouldn't be that present if you haven't configured LaTeX. In other words,
my only complaint is about the number of errors that LyX shows the user, a
single occurrence would be better.
> > > - nested bullet points in listings shifted by an inch and overlap with
> > > text - e.g. section 2.8, 3.1.4, 3.7.6 etc
> > >
> >
> > That's both a CSS and an HTML issue: CSS for the subitems (like Ctrl in
> > 2.8), HTML for continuing items (like Alt in 2.8). For the CSS part,
> adding
> > this rule seems to help:
> >
> > li.labeling_item ul, li.labeling_item ol {
> > text-indent: 0;
> > margin-left: -5em;
> > }
> >
> > However, the result with nested lists is still very poor (with ".."
> being a
> > subitem to Home and End):
> >
> > [image: image.png]
>
> Not great indeed, but better than the current situation.
>
> > The problem is that this is configured in most layouts (HTMLStyle block),
> > so it is painful to fix.
> >
> > The best solution in the long term, in my opinion, is to switch to HTML
> > definition lists, which is semantically correct (while the current output
> > is not a good use of lists). It mostly works out of the box, with no CSS
> > changes. I believe the C++ changes would be quite minimal, but it would
> > break any custom CSS. I am attaching an excerpt from the User's guide:
> > `UserGuide_list.xhtml` for the current output, `UserGuide_list -
> > Copy.xhtml` for my proposed refactoring. The result is quite close to
> what
> > we have in LyX. I bet this change should be delayed to 2.4.1, as it might
> > break a bit more, or even 2.5 if we consider this kind of change
> breaking.
>
> Riki, might want to chime in here as he was behind original xhtml design.
> I find switch to html lists conceptually better, though they are visually
> somewhat distinct - label is on it's own line AFAICS.
>
That's fixable, for instance
https://stackoverflow.com/questions/1713048/how-to-style-dt-and-dd-so-they-are-on-the-same-line.
> When it comes to timing:
> - CSS change could go IMHO into 2.4.0, but it will break custom CSS anyway
> right?
>
It might break some of the custom CSS.
> - I do not know how C++ changes would look like, if they are indeed minimal
> I would consider them for 2.4 as well. I understand that it might break
> custom CSS but at the moment we are producing trash by default.
>
I dug deeper into the problem. Actually, it will require some change in the
module format to specify that the label must be output outside the item in
InsetText. With the current code, here is the best I can get:
<dl class='labeling'>
<dd class="labeling_item" id='magicparlabel-0'><dt
class="labeling_label">Label</dt>
desc</dd>
</dl>
The change is that a Style should allow an HTMLInnerTag. A layout
configuration like this should suffice, otherwise:
Style Labeling
HTMLTag dl
HTMLItem NONE
HTMLLabel dt
HTMLInnerTag dd
HTMLInnerTag already exists, but not in Style, only in InsetLayout.
Riki?
>
>
>
> > > - horrible image sizing - e.g. section 3.3.1, 4.2, 4.4, 4.6, 6.11.1,
> 6.17,
> > > A.9.1/2
> > >
> >
> > Modern CSS can use `scale:` instead of `width:` to mimic the meaning of
> > LyX' display factor better. I have pushed this as
> > f2660d172c3f38e2dad1f32d7b3b4d953e2efb8a. Here is the result I get, which
> > is better (but not exactly what I wanted):
> >
> > [image: image.png]
> >
> > Notice the space around the image. I could not find a solution to this
> > problem. If the scale factor is over 100%, the bounding box (used to draw
> > text) will be the one of the image file while the contents will be scaled
> > (and go outside the bounding box). Here is an example with 170%:
> >
> > [image: image.png]
> >
> > I believe this is a limitation of LyX' system: HTML supposes you don't
> have
> > oversized images, while it is very common in LaTeX to scale images so
> that
> > they fit your layout. Any solution welcome :)!
> > For now, I think that f2660d172c3f38e2dad1f32d7b3b4d953e2efb8a should
> stay
> > on 2.5 and not be backported (unless there is a consensus that this is
> > closer to the behaviour we want).
>
> I have ongoing issues how to handle images consistently for documents
> used for output of both pdf & html - to the extent that I was considering
> to make fileformat change and create new setting for images. It would
> contain
> size for xhtml output itself.
>
> I can easily do the UI/fileformat part but I am not well versed in html
> world. Is single setting for % size enough or are there multiple
> common-sense
> ways how to specify image size? And should that be the same with docbook?
>
> Do you think creating new option is sensible solution here, will you help
> me with the html/xml part if we go this way?
>
> ATM we could use your 2.5 patch to produce LyX manuals.
>
Having the size in pixels would be best! In that case, we can use the usual
width/height attributes.
I am not sure that a UI change is required for most cases: we could read
the image size and apply the scale ratio, that's what most users will want,
I believe (or have an HTML scale, optionally different from the LaTeX
scale). Some people will probably want to have something specific for their
HTML output, but that is more advanced. (If you want to do something more
complete for DocBook, you'd need to specify the viewport and the content
sizes: https://tdg.docbook.org/tdg/5.2/imagedata. But you can also give
different images with different size attributes for the various formats --
Web and print, typically --, but I'm not willing to go that route, as it
would be a complex UI and LyX isn't really a DocBook editor.)
In any case, I can give a hand for the HTML/DocBook parts :)!
PS. I had an epiphany when reading your message: LyX already computes a
size for each image! I just pushed
ce5f84ff02e04a10d345776571ae0a2439b09e8f, which is a cleaner solution when
the user gives a scale, with no drawback AFAICT.
> > > - math broken: 5.1.4: "Invalid Markup"
> > >
> >
> > I cannot reproduce with the current version (2.5.0~dev):
> >
> > [image: image.png]
>
> Might be browser-related. I checked now on my work computer with firefox
> 115
> and it's indeed rendered ok. Will check on other setups.
>
> > > - url is text instead of url: 6.3.1, 6.15, 6.16.1 (wrong url anyway)
> > >
> >
> > This is not possible with the current layout format. URLs are implemented
> > as flex insets, with many parameters, but the current design forces that
> > the flex inset outputs its contents only once. For this two work, we'd
> need
> > to output it twice: as text and as a parameter. It doesn't look not too
> > hard to implement (my current bet is on InsetText::insetAsXHTML, around
> > writing the opening outer tag with `htmltag()`), but we need a new layout
> > version, hence not in scope for 2.4.
> >
> > - bibliography items has the same huge fonts size as the section heading
> > >
> >
> > Actually, they are output as headings (`h2`). However, I don't understand
> > anything about the HTML bibliography code (which is why it is completely
> > different in DocBook) :/. I don't understand how to set the HTMLTag for
> > bibliography items (it's always reset to `h2` when reaching
> > `xhtmlParagraphs` from `output_xhtml.cpp`'s `makeBibliography`). If
> anyone
> > understands the code well enough :). (Otherwise, maybe it'd be good to
> > rewrite it to be more similar to DocBook.)
>
> Riki imght have some idea? Otherwise I will forward this issue to trac so
> we
> have it on the list.
>
> > > - some nomenclanture links do not work (e.g. try "Shift" or "Alt")
> > >
> >
> > Some magic IDs are not output, especially for list items. That's what I'm
> > changing in 2d86b881242c3ea4756af28f8458aeb7cbfa6822, a candidate for
> > backporting to 2.4.1.
>
> I endorse this. Riki?
>
> Pavel
>
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
