[tex4ht] [bug #513] Missing vertical space after first paragraph in lists

[Ulrich Müller]

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

Thank you for the quick response.

That .cfg file fixes the problem for me.


___

Reply to this item at:

  

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

[tex4ht] [bug #513] Missing vertical space after first paragraph in lists

[Ulrich Müller]

Additional Item Attachment, bug #513 (project tex4ht):

File name: bug.texSize:0 KB
File name: bug.html   Size:1 KB
File name: bug.cssSize:5 KB


___

Reply to this item at:

  

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

[tex4ht] [bug #513] Missing vertical space after first paragraph in lists

[Ulrich Müller]

URL:
  

 Summary: Missing vertical space after first paragraph in
lists
 Project: tex4ht
Submitted by: ulm
Submitted on: Thu Jun  3 11:08:19 2021
Category: None
Priority: 5 - Normal
Severity: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

If a list item has multiple paragraphs, then there is no vertical space
between the first and second paragraph. Subsequent paragraphs
are o.k.

(Looking at the output, the first paragraph isn't a paragraph in HTML.)

See attached minimum example.




___

File Attachments:


---
Date: Thu Jun  3 11:08:19 2021  Name: bug.tex  Size: 78B   By: ulm


---
Date: Thu Jun  3 11:08:19 2021  Name: bug.html  Size: 1kB   By: ulm


---
Date: Thu Jun  3 11:08:19 2021  Name: bug.css  Size: 5kB   By: ulm



___

Reply to this item at:

  

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

[tex4ht] [bug #510] Error with hyperref and \include

[Ulrich Müller]

Additional Item Attachment, bug #510 (project tex4ht):

File name: buginclude.aux Size:0 KB


___

Reply to this item at:

  

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

[tex4ht] [bug #508] Error after loading hyperref from a class file

[Ulrich Müller]

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

Thank you, this has fixed the original bug.

Unfortunately, a new issue with hyperref has surfaced. I've filed bug #510 for
it.


___

Reply to this item at:

  

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

[tex4ht] [bug #510] Error with hyperref and \include

[Ulrich Müller]

URL:
  

 Summary: Error with hyperref and \include
 Project: tex4ht
Submitted by: ulm
Submitted on: Wed Apr 28 13:49:49 2021
Category: None
Priority: 5 - Normal
Severity: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

As in bug #508, I load hyperref from a class file. Additionally, the main file
uses \include to include a separate file.

This results in the following error:

! Extra \else.
\@include ...ediate \closeout \@partaux \fi \else 
  \deadcycles \z@ \@nameuse
...
l.3 \include{buginclude}

To reproduce, run "mk4ht xhlatex bug" with the attached bug.tex, bugclass.cls,
and buginclude.tex. The full log file is attached too.

I am using r59007 from the texlive repository:
https://www.tug.org/svn/texlive?view=revision=59007




___

File Attachments:


---
Date: Wed Apr 28 13:49:50 2021  Name: bugclass.cls  Size: 96B   By: ulm


---
Date: Wed Apr 28 13:49:50 2021  Name: bug.log  Size: 20kB   By: ulm


---
Date: Wed Apr 28 13:49:49 2021  Name: bug.tex  Size: 78B   By: ulm


---
Date: Wed Apr 28 13:49:49 2021  Name: buginclude.tex  Size: 22B   By: ulm



___

Reply to this item at:

  

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

[tex4ht] [bug #508] Error after loading hyperref from a class file

[Ulrich Müller]

URL:
  

 Summary: Error after loading hyperref from a class file
 Project: tex4ht
Submitted by: ulm
Submitted on: Tue Apr 27 12:11:34 2021
Category: None
Priority: 5 - Normal
Severity: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

When loading the hyperref package from a class file, I get the following error
when the first \label is encountered:

! Argument of \strip@prefix has an extra }.
 
\par 
l.3 \label{foo}

To reproduce, run "mk4ht xhlatex bug" with the attached bug.tex and
bugclass.cls. The full log file is attached too.

I see this problem with TeX Live 2021 but not with 2020.

As a workaround, I postpone loading of hyperref:
\g@addto@macro\@documentclasshook{\RequirePackage{hyperref}}
So looks like load order matters.




___

File Attachments:


---
Date: Tue Apr 27 12:11:34 2021  Name: bug.tex  Size: 74B   By: ulm


---
Date: Tue Apr 27 12:11:34 2021  Name: bugclass.cls  Size: 96B   By: ulm


---
Date: Tue Apr 27 12:11:34 2021  Name: bug.log  Size: 20kB   By: ulm



___

Reply to this item at:

  

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

[tex4ht] [bug #472] src/htcmd.c fails to compile with format-security

[Ulrich Müller]

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

The Gentoo package compiles and installs htcmd for some reason (presumably
https://bugs.gentoo.org/85301#c2 which is a little weak indeed), so the
format-security issue has popped up in an automatic scan.

Looking at the source code, the command seems to do conversion from slashes to
backslashes in path names, which doesn't look useful outside of the
MS-DOS/Windows world.

BTW, there may be more security issues: warn_err_mssg[] has only one element
and err_i() accesses it out of bounds. The command line buffer is allocated
with a fixed size and populated without any size checks.

So, I'm going to drop htcmd from the Gentoo package. Sorry for the noise.


___

Reply to this item at:

  

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

[tex4ht] [bug #472] src/htcmd.c fails to compile with format-security

[Ulrich Müller]

URL:
  

 Summary: src/htcmd.c fails to compile with format-security
 Project: tex4ht
Submitted by: ulm
Submitted on: Mon 29 Jun 2020 09:48:45 AM EEST
Category: None
Priority: 5 - Normal
Severity: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Forwarding downstream bug: https://bugs.gentoo.org/554636

src/htcmd.c fails to compile with format-security (which many distros use to
build their packages). To reproduce, use -Werror=format-security in gcc
flags.

More info at https://fedoraproject.org/wiki/Format-Security-FAQ

See attached patch for a fix.




___

File Attachments:


---
Date: Mon 29 Jun 2020 09:48:45 AM EEST  Name: tex4ht-format-security.patch 
Size: 510B   By: ulm



___

Reply to this item at:

  

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

[tex4ht] [bug #313] Irregular formatting of longtable entries in list of tables

[Ulrich Müller]

Follow-up Comment #7, bug #313 (project tex4ht):

Would you prefer if I filed a separate bug for the caption.{sty,4ht} problem?

The longtable problem that I had originally reported is fixed by the new
longtable.4ht (file #346).


___

Reply to this item at:

  

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

[tex4ht] [bug #313] Irregular formatting of longtable entries in list of tables

[Ulrich Müller]

Follow-up Comment #6, bug #313 (project tex4ht):

Indeed, with the minimal example I had attached (bug.tex) the TOC appears to
be correct.

Further investigation shows that the bad TOC entries for tables are caused by
some interaction with the caption package (version 2020/01/03 v3.4h). I am
going to attach a new minimal example.

If I replace the caption package by the one that was shipped with TeX Live
2019 (version 2018/10/06 v3.3-154), the TOC entries are fine.


(file #348)
___

Additional Item Attachment:

File name: bug2.tex   Size:0 KB


___

Reply to this item at:

  

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

[tex4ht] [bug #313] Irregular formatting of longtable entries in list of tables

[Ulrich Müller]

Follow-up Comment #4, bug #313 (project tex4ht):

Yes, now the longtable entries in the TOC look like the section entries, i.e.
the link does _not_ include the table's number.

But as I said yesterday, with TeX Live 2020 the TOC entries for normal tables
are broken as well. Not sure if that is a regression in tex4ht itself, or
caused by some other change from TeX Live 2019 to 2020.


___

Reply to this item at:

  

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

[tex4ht] [bug #313] Irregular formatting of longtable entries in list of tables

[Ulrich Müller]

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

Update: With TeX Live 2020, the table's number is included inside of the link
also for normal tables.

In other words, it is now consistent within the list of tables, but it is
inconsistent with the table of contents.


___

Reply to this item at:

  

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

[tex4ht] [bug #420] The CSS "white-space" property has no value "wrap"

[Ulrich Müller]

Follow-up Comment #1, bug #420 (project tex4ht):

A minimal example white-space.tex is attached.

The resulting HTML output is attached as white-space.html. It has been
generated with:
$ mk4ht xhlatex white-space


___

Reply to this item at:

  

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

[tex4ht] [bug #420] The CSS "white-space" property has no value "wrap"

[Ulrich Müller]

URL:
  

 Summary: The CSS "white-space" property has no value "wrap"
 Project: tex4ht
Submitted by: ulm
Submitted on: Wed 13 Mar 2019 01:13:49 PM EET
Category: None
Priority: 5 - Normal
Severity: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

For paragraph columns in the tabular environment, tex4ht produces 
elements with style="white-space:wrap".

However, the CSS "white-space" property has no value "wrap":
https://www.w3.org/TR/CSS21/text.html#white-space-prop

The CSS validator at http://jigsaw.w3.org/css-validator/ complains about this,
with the following error message:
Value Error : white-space wrap is not a white-space value : wrap 

IIUC, the correct value to obtain the desired behaviour would be
white-space:normal, so presumably all occurences of white-space:wrap in
html4.4ht and javahelp.4ht should replaced by that.




___

File Attachments:


---
Date: Wed 13 Mar 2019 01:13:49 PM EET  Name: white-space.tex  Size: 103B   By:
ulm


---
Date: Wed 13 Mar 2019 01:13:49 PM EET  Name: white-space.html  Size: 1kB   By:
ulm



___

Reply to this item at:

  

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

[tex4ht] [bug #313] Irregular formatting of longtable entries in list of tables

[Ulrich Müller]

Follow-up Comment #1, bug #313 (project tex4ht):

Downstream (Gentoo Linux) bug: https://bugs.gentoo.org/580530


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Puszcza
  http://puszcza.gnu.org.ua/

[tex4ht] [bug #313] Irregular formatting of longtable entries in list of tables

[Ulrich Müller]

URL:
  

 Summary: Irregular formatting of longtable entries in list of
tables
 Project: tex4ht
Submitted by: ulm
Submitted on: Sa 11 Jun 2016 19:20:11 EEST
Category: None
Priority: 5 - Normal
Severity: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

In the list of tables, entries for longtables include the table's number
inside of the link, whereas entries for normal tables (or for figures) don't
include it.

The generated HTML for a table entry looks like this:

1A table

Whereas for a longtable it is:

2 
  A longtable

I am attaching a minimal example to reproduce the bug in bug.tex and the
output generated with "mk4ht xhlatex bug" as bug.html.




___

File Attachments:


---
Date: Sa 11 Jun 2016 19:20:11 EEST  Name: bug.tex  Size: 202B   By: ulm


---
Date: Sa 11 Jun 2016 19:20:11 EEST  Name: bug.html  Size: 3kB   By: ulm



___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Puszcza
  http://puszcza.gnu.org.ua/