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
The last version I had used (v0.18) prior to the current release, seemed to handle the creation of columns (for/in Microsoft Word) that, based on the twip, seemed to correlate to the appropriate inches (via internal Microsoft Word ruler) when rendered. I only needed to assign a width to a single cell within the row for the column (as shown below, this is the TIME column), and the other columns would auto-fit the content.
For version 1.2.0, this functionality has seemingly regressed for rendering in Microsoft Word (2016). LibreOffice appears to render better, but still incorrectly. I believe this is because PhpWord is now explicitly assigning column sizes in the document.xml file.
Microsoft Word 2016 on PhpWord v0.18
Libre Office v24.2.0.3 on PhpWord v0.18
Microsoft Word 2016 on PhpWord v1.2.0
Libre Office v24.2.0.3 on PhpWord 1.2.0
In trying to track down the rendering differences between versions, I examined the uncompressed XML files to try to identify differences. The most glaring was in word/document.xml in the w:tblGrid definition. In version 0.18 the widths were only defined for the columns explicitly provided via PhpWord code/style, the other columns had no width attribute. This, however, had a detrimental impact on LibreOffice Writer. The updates may have caused a different result in rendering, and an unexpected one, but at least the rendering is the same in both editors. That said, attempting to modify the column width attributes and recompressing to a DOCX file did not provide any level of correction, so there must be a few other places where widths are defined.
For reference, in v0.18, the column's Preferred Width in Microsoft Word was defined as 1.39". For v1.2.0, it is still reporting a Preferred Width of 1.39"...but is very obviously being prevented from rendering that way, from something else.
Steps to Reproduce
Please provide a code sample that reproduces the issue.
The expectation was that the 2000 twip units on the TIME column would've been set to the converted 1.39" column width, and the other columns would've auto-fit.
Current Behavior
The preferred width is set, but it seems that the other columns are overriding widths in some sort of calculated width...
Context
Please fill in your environment information:
PHP Version: 8.2
PHPWord Version: 1.2.0
The text was updated successfully, but these errors were encountered:
Describe the Bug
The last version I had used (v0.18) prior to the current release, seemed to handle the creation of columns (for/in Microsoft Word) that, based on the twip, seemed to correlate to the appropriate inches (via internal Microsoft Word ruler) when rendered. I only needed to assign a width to a single cell within the row for the column (as shown below, this is the TIME column), and the other columns would auto-fit the content.
For version 1.2.0, this functionality has seemingly regressed for rendering in Microsoft Word (2016). LibreOffice appears to render better, but still incorrectly. I believe this is because PhpWord is now explicitly assigning column sizes in the
document.xml
file.Microsoft Word 2016 on PhpWord v0.18
Libre Office v24.2.0.3 on PhpWord v0.18
Microsoft Word 2016 on PhpWord v1.2.0
Libre Office v24.2.0.3 on PhpWord 1.2.0
In trying to track down the rendering differences between versions, I examined the uncompressed XML files to try to identify differences. The most glaring was in
word/document.xml
in the w:tblGrid definition. In version 0.18 the widths were only defined for the columns explicitly provided via PhpWord code/style, the other columns had no width attribute. This, however, had a detrimental impact on LibreOffice Writer. The updates may have caused a different result in rendering, and an unexpected one, but at least the rendering is the same in both editors. That said, attempting to modify the column width attributes and recompressing to a DOCX file did not provide any level of correction, so there must be a few other places where widths are defined.For reference, in v0.18, the column's Preferred Width in Microsoft Word was defined as 1.39". For v1.2.0, it is still reporting a Preferred Width of 1.39"...but is very obviously being prevented from rendering that way, from something else.
Steps to Reproduce
Please provide a code sample that reproduces the issue.
Expected Behavior
The expectation was that the 2000 twip units on the TIME column would've been set to the converted 1.39" column width, and the other columns would've auto-fit.
Current Behavior
The preferred width is set, but it seems that the other columns are overriding widths in some sort of calculated width...
Context
Please fill in your environment information:
The text was updated successfully, but these errors were encountered: