HTML import filter very (too) basic
jens.troeger at light-speed.de
Wed Jan 9 13:17:48 UTC 2019
If I had to take a guess then I’d say that the problem shown in the initial image is caused by the CSS class resolution. The HTML div is there (see the grey border) but it looks like the CSS of the div does not propagate correctly.
I’ll file a bug, but if I had to fix it I’d start digging around in that CSS resolution for nested elements (both, div and span)… 🤓
> On Jan 9, 2019, at 20:22, Noel Grandin <noelgrandin at gmail.com> wrote:
> On Wed, 9 Jan 2019 at 10:25, Jens Tröger <jens.troeger at light-speed.de> wrote:
> > On Jan 9, 2019, at 16:06, Noel Grandin <noelgrandin at gmail.com> wrote:
> > Nobody owns it, and you're welcome to file a bug, but there are already a ton of HTML import bugs, our support is really very basic.
> Well I’ve noticed in the past that bugs regarding the HTML filter received very little attention, unfortunately. If not the existing import filter, are there efforts to implement alternatives?
> HTML is a fairly massive beast, so there are __always__ going to be bugs in our import filter.
> I believe that Kohei started doing some parsing work over in the orcus library at
> and we use some of that (e.g. very very basic CSS parsing) somewhere in our code.
> But for normal HTML we still use our own parser.
> And the parsing is only a very small part anyhow, most of the work is in converting the HTML model to our own document model.
> Unfortunately, while I’m very comfortable with C++ and Linux etc, LO seems like a magnificent beast of code and I am unable to judge whether I’d be useful tackling these issues myself. It would be great to find whoever knows the code to discuss…
> Come hang out on the IRC channel and ask questions. Nobody really owns it, but various people have some knowledge about different parts of it and can point you in the right direction.
> The bulk of the logic lives in
More information about the LibreOffice