Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix and modernize contents of head (according to vnu checker) #49

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

cspiel
Copy link
Contributor

@cspiel cspiel commented Nov 9, 2020

The vnu checker as of version 20.6.30 always turns up the following
problems with Hevea-generated HTML files (edited for clarity):

Line 4: error: Internal encoding declaration "us-ascii" disagrees
               with the actual encoding of the document ("utf-8").
Line 4: error: Bad value "text/html; charset=US-ASCII" for
               attribute "content" on element "meta": "charset="
               must be followed by "utf-8".
Line 6: info warning: The "type" attribute for the "style"
                      element is not needed and should be omitted.

This P/R addresses all three diagnostics.

In the course of fixing the problems it turned out that a new
(internal) macro \@print@endline would be beneficial for
the clarity and simplicity of expression. So the P/R has been
split into three patches:

  1. Introduce and document \@print@endline.
  2. Use the new macro in every position where \@print
    needs to add a final newline character.
  3. Fix macro \@meta which generates the relevant part
    of the head-element's contents. Update intertwined lexers
    accordingly.

With this P/R Hevea generates vnu-clean headers.

which behaves like `\@print', but adds an endline character
to the output.  Update the documentation accordingly.
according to vnu warnings.  Reformat macro `\@meta'
along the way.
@maranget
Copy link
Owner

maranget commented Nov 9, 2020

Hi thanks again for your contribution.

Did your check the impact of this PR on changing the document input (and output) charset, as documented here in the user manual?

@cspiel
Copy link
Contributor Author

cspiel commented Nov 13, 2020

@maranget: Sure, I have checked that this change does not break
output encodings. 😉

Following the link you gave me, I found that the documentation of
package inputenc.hva would benefit of a comprehensive table that
lists all available encodings, their character sets and their relations
to LaTeX's inputenc.sty. Done in 2824a6b.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants