You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on the discussion #1868 I started a research of the font-size styling topic to test different situations
what the font-size result will be given in compare of HTML -> (PDF ->) DOCX.
The styling from HTML to PDF is ok but a special situation with the font-size "12pt" cause a wrong style conversion in DOCX-documents.
The problem is that the HTML-content of the BIRT-elements "text", "dynamic text", "data" will not parsed into full supported DOCX-elements. Instead of a full parser the archive-/intermediate-format MHT(ML) will be used. These files embedded like external documents into the DOCX and will be converted through Word into the DOCX-elements.
example of the internal DOCX-structure with MHT-files created by BIRT
And there exists a kind of standard error on MS Word side because the font size "12pt" will be converted in every case into "10pt".
This topic is given at the HTML-tags "div" & "span" but also the HTML4.0-element font is not converted correctly for result size "12pt".
(BIRT produce the DOCX-Version: WordProcessingML, Version 2016)
I tried to replace the "div"-tag with the "p"-tag (paragraph). But the converting of Word is not the same for these both elements
so we would get side effects of styling. In special cases the styling of a p-tag will override the style of following elements.
Normally the best way would be to implements a DOCX-parser to avoid MHT-files but for that large efforts are needed to get it.
(Note: DOC-files from BIRT 4.6 was created correctly, for that file format a kind of HTML-parser is implemented but cannot used for DOCX.)
The smallest workaround is to use another font-size instead of "12pt" to get a better result.
So I will provide a PR that the font-size will be changed from "12pt" to "12.5pt".
I know this isn't the same font-size and therefore I call it workaround. But it is better like the currenty situation.
Note: The behavior of #1868 was not reproducable on my side.
Example 01 of wrong converting
Example 02 of wrong converting
The text was updated successfully, but these errors were encountered:
Based on the discussion #1868 I started a research of the font-size styling topic to test different situations
what the font-size result will be given in compare of HTML -> (PDF ->) DOCX.
The styling from HTML to PDF is ok but a special situation with the font-size "12pt" cause a wrong style conversion in DOCX-documents.
The problem is that the HTML-content of the BIRT-elements "text", "dynamic text", "data" will not parsed into full supported DOCX-elements. Instead of a full parser the archive-/intermediate-format MHT(ML) will be used. These files embedded like external documents into the DOCX and will be converted through Word into the DOCX-elements.
example of the internal DOCX-structure with MHT-files created by BIRT
And there exists a kind of standard error on MS Word side because the font size "12pt" will be converted in every case into "10pt".
This topic is given at the HTML-tags "div" & "span" but also the HTML4.0-element font is not converted correctly for result size "12pt".
(BIRT produce the DOCX-Version: WordProcessingML, Version 2016)
I tried to replace the "div"-tag with the "p"-tag (paragraph). But the converting of Word is not the same for these both elements
so we would get side effects of styling. In special cases the styling of a p-tag will override the style of following elements.
Normally the best way would be to implements a DOCX-parser to avoid MHT-files but for that large efforts are needed to get it.
(Note: DOC-files from BIRT 4.6 was created correctly, for that file format a kind of HTML-parser is implemented but cannot used for DOCX.)
The smallest workaround is to use another font-size instead of "12pt" to get a better result.
So I will provide a PR that the font-size will be changed from "12pt" to "12.5pt".
I know this isn't the same font-size and therefore I call it workaround. But it is better like the currenty situation.
Note: The behavior of #1868 was not reproducable on my side.
Example 01 of wrong converting
Example 02 of wrong converting
The text was updated successfully, but these errors were encountered: