[tex4ht] [bug #623] Images inverted with dark mode by default html5 css

[Oliver Freyermuth]

Follow-up Comment #2, bug #623 (project tex4ht):

Dear Michal,

aaah, I see. In fact, my problems were seen with TikZpictures, i.e. I'm the
same guy from here:
https://tex.stackexchange.com/a/641354/224985

The black pgfornaments became invisible with a dark theme for me by default,
which confused me at first. I then tried with a colourful TikZ picture and saw
the colours became inverted, i.e. I used:

\tikzset{pgfornamentstyle/.style={color=black,fill=yellow, opacity=0.7,
line width=0.5pt}};
\node[anchor=south]{\pgfornament[height=1.0cm]{87}};

within that example and the ornaments came up with a blue fill colour. But you
are fully correct, it does not happen to \includegraphics. 

The CSS config you added works perfectly fine for me in the case of black TikZ
images, it makes them visible nicely and the body and text are well adapted to
the dark theme. So I think this is a large improvement to the default :-). 

___

Reply to this item at:

  

___
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/

[tex4ht] [bug #623] Images inverted with dark mode by default html5 css

[Oliver Freyermuth]

URL:
  

 Summary: Images inverted with dark mode by default html5 css
 Project: tex4ht
Submitted by: olifre
Submitted on: Tue Apr  9 00:38:42 2024
Category: None
Priority: 5 - Normal
Severity: 3 - Minor
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Dear Karl,

feel free to close if this is intended — after updating from TeXlive 2021 to
2023, I noticed that with the default CSS and HTML5 mode in a dark-themed
browser, all image colours are inverted. 

Body background colour and text colours are unaffected, but images are caught
by the rule:

\Css{
  @media (prefers-color-scheme: dark) {
img[src^="\jobname"]{filter: invert(1); }
  }
}

which was added in
https://tug.org/svn/texlive/trunk/Master/texmf-dist/source/generic/tex4ht/tex4ht-html5.tex?r1=64099=65513
. The comment there mentions this is a fix for:
"background of generated images in the dark mode"
so I presume it was added on purpose. 

It seems quite irritating for a default — black graphics (e.g. pgfornaments)
vanish against the white background when shown in a dark-themed browser, and
photos get inverted colours. 

I'm personally using:

filter: drop-shadow(7px 7px 4px rgba(0, 0, 0, .7)) invert(0) !important;

in my CSS for all images to overwrite that. and of course "nostyle" might be
what I should actually be using when using a custom CSS. 

As outlined, if the default is intended, feel free to close. 
Thanks!




___

Reply to this item at:

  

___
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/

[tex4ht] [bug #611] Random SIGSEGV of tex4ht due to invalid memory accesses

[Oliver Freyermuth]

Follow-up Comment #5, bug #611 (project tex4ht):

Hi again Karl,

many thanks! I don't see any problem with the memset call, and can confirm
this also makes valgrind blissfully silent on my end when applying the patches
to tex4ht on my local desktop (Gentoo Linux). I tested with various documents
and various parameters and found no problems. 

Since Gentoo currently seems to package an old snapshot of tex4ht based on a
not-directly-upstream source, I have pinged the corresponding maintainer to
pull in the fixes or ideally just switch to upstream ( for reference:
https://bugs.gentoo.org/915782 ). 

In my CI/CD pipeline which I am running via GitHub actions to produce HTML
pages for deployment with GitHub pages, I am actually relying on Docker
containers based on Alpine Linux with Texlive binaries installed via tlmgr.
Hence, that would be x86_64-linuxmusl binaries. In case those are easy for you
to build, of course that would be appreciated, if not, waiting for TL24 is
also fine for me (it's not that far off, and knowing the issue is fixed for
good makes me very happy :-) ). 

Cheers and many thanks for fixing things so quickly! 

___

Reply to this item at:

  

___
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/

[tex4ht] [bug #611] Random SIGSEGV of tex4ht due to invalid memory accesses

[Oliver Freyermuth]

Follow-up Comment #3, bug #611 (project tex4ht):

Hi Karl,

many thanks! That does indeed look very reasonable (and straightforward) as a
fix. Testing it locally expectedly also removes the invalid read on my machine
:-). 

Thanks to you for taking care of this (very valuable) tool and of the report
so quickly! 

Since the main place in which I have hit the "Illegal storage address" issue
is in a CI/CD environment which uses monthly texlive snapshots (via
containers), I'll then automatically get the fix in there with the next
monthly snapshot once it is in texlive. 

Thanks a lot, and keeping my fingers crossed hoping the fix for the
uninitialized values is also not too much effort, 

___

Reply to this item at:

  

___
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/

[tex4ht] [bug #611] Random SIGSEGV of tex4ht due to invalid memory accesses

[Oliver Freyermuth]

URL:
  

 Summary: Random SIGSEGV of tex4ht due to invalid memory
accesses
 Project: tex4ht
Submitted by: olifre
Submitted on: Thu Oct  5 19:31:55 2023
Category: None
Priority: 5 - Normal
Severity: 7 - Important
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

I've been haunted by "Illegal storage address" for large documents with many
fonts for quite a while (coming and going with tex4ht releases and even
changing depending on shell environment), and often, unrelated changes in the
document (e.g. reducing fonts) fix it. 

I believe I have finally hunted down the underlying issue to an invalid memory
access in tex4ht — reproducible with an MWE (which does not crash), visible
with valgrind / gdb. 


Reporducer:

1) Create foo.tex with content:
-
\documentclass{scrbook}

\begin{document}
  \section{foo}
  \subsection{bar}
  Foo
\end{document}
--

2) Run:
   make4ht --utf8 --output-dir html foo

3) Re-run the tex4ht step with valgrind:
   valgrind tex4ht -cmozhtf -utf8 foo.dvi

This reveals:
-
==4487== Conditional jump or move depends on uninitialised value(s)
==4487==at 0x10EE14: main (tex4ht.c:8099)
==4487== 
==4487== (action on error) vgdb me ... 
==4487== Continuing ...
==4487== Conditional jump or move depends on uninitialised value(s)
==4487==at 0x10EE16: main (tex4ht.c:8108)
==4487== 
==4487== (action on error) vgdb me ... 
==4487== Continuing ...
==4487== Invalid read of size 4
==4487==at 0x10E794: main (tex4ht.c:8741)
==4487==  Address 0x8beb1f8 is 8 bytes before a block of size 2 alloc'd
==4487==at 0x48407C4: malloc (vg_replace_malloc.c:431)
==4487==by 0x11851B: malloc_chk (tex4ht.c:1481)
==4487==by 0x10EC30: main (tex4ht.c:7104)
==4487== 
-

The invalid read is most worrisome, it originates from the source lines:

8740if( span_on && !in_span_ch  && !ignore_chs && !in_accenting
8741&& (default_font != font_tbl[cur_fnt].num) ){

It is caused by the part:
   (default_font != font_tbl[cur_fnt].num) 
being evaluated, while the index cur_fmt is negative:

(gdb) p default_font
$12 = -1
(gdb) p cur_fnt 
$13 = -1

This yields an invalid read. If the document has many (many!) fonts, the
dynamically allocated and subsequently freed memory from opendir/closedir
looking for the htf files ends up right before the font_tbl array, and
depending on page boundaries, this read with negative index may yield an
invalid read / SIGSEGV. 

Since I don't understand the full logic of the code, I'm not fit to propose a
(good) fix. 

It seems this might be affecting other users, too, looking for reports of
"Illegal storage address" on tex stackexchange which in some cases were
"fixed" by unrelated document changes. 



Nota bene:
The two "Conditional jump or move depends on uninitialised value(s)" are from
the lines:
  if( value == htf_4hf[mid].ch ){
and
  } else if( value < htf_4hf[mid].ch ){
since htf_4hf seems to be used (in some cases) before being initialized. This
does not lead to a crash, though, since it's not an invalid read. 




___

Reply to this item at:

  

___
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/