path: root/.git-hooks
diff options
authorJustin Luth <>2017-09-07 21:07:40 -0400
committerMiklos Vajna <>2017-09-11 12:31:19 +0200
commitc14be5f5545768fc06bd1e3900e076dc28be2649 (patch)
tree24f45f6c2bab35d060707229193b70a5bb0e1a15 /.git-hooks
parent020c3eebc2435c4a03076c99e36b5f144e358fe5 (diff)
tdf#97648 vml import: fix horizontalLine percentage
o:hrpct (horizontal line width as a percentage) was overwriting valid widths with an invalid string since 2012. For some reason, commit 96c7ab19b77c2f90acd4c34552474b0f616f48a7 thought it would be a good idea to set the width as a percent string, even though the code doesn't seem to handle percent strings. (like "100%"). The logic was that since 100% width is saved as nWidth=0 by Microsoft, so it doesn't make a difference. Well, it does make a difference for every other percentage, since nWidth IS provided for those. That width value is the only thing LO can currently handle - it does nothing with the maWidthPercent for these horizontal lines. Saving hrpct to maWidthPercent seems like the proper variable for this data, but once again, this doesn't in fact change much in LO. It certainly doesn't affect the width of the line. Since this patch only affects o:hr shapes, this is a pretty safe change, for the benefit of all <100% o:hrpct's. An "assert false" and "make check" only showed docs containing 100%, width=0 samples. I added a unit test for several other lengths. I also hacked that test to provide a width value for the 100% line - even though that is not natural - just so it can be seen in LO. Change-Id: I9d6ddbbaa99ec8df32abb1047a80522322a1f631 Reviewed-on: Tested-by: Jenkins <> Reviewed-by: Miklos Vajna <>
Diffstat (limited to '.git-hooks')
0 files changed, 0 insertions, 0 deletions