-
Notifications
You must be signed in to change notification settings - Fork 16
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
Underlining doesn't work when color isn't also specified #36
Comments
Hi |
I just tested, and it appears that Word does fall back to the text’s color
when no color is explicitly set on the <w:u> element.
I’ll submit a pull request for a change that looks for underlineColor only,
then.
…On Jan 26, 2023 at 01:39:21, Morten ***@***.***> wrote:
Hi
thank you for catching this. It seems my original implementation of
underlines was a bit lackadaisical. I guess I was not aware that the color
was optional for the <w:u> element.
I agree with your second suggestion - drop the requirement for a
backgroundcolor and use NSAttributedString.Key. underlineColor for
user-specified colors. We should test if the fallback to foregroundColor is
required in DocX or if Word does this automatically.
—
Reply to this email directly, view it on GitHub
<#36 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADXE3PWVYAWJZFZVL456MODWUJA4TANCNFSM6AAAAAAUGZ3UEU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Fixed in #37 . Thank you for addressing this! |
If you have an attributed string and apply
NSAttributedString.Key.underlineStyle
to it, the generated docx will not include that underline. This is because DocX requires thatforegroundColor
must be set, otherwise the<w:u>
element won't be output.Since the
w:color
value is optional in the docx, I don't think this should be required. I have a fix ready that makes thecolor
argument Optional in theunderlineElement
function.That said, I'm not sure using the
foregroundColor
is correct either, sinceNSAttributedString.Key.underlineColor
exists for the purpose. If existing code relies on this behavior, though, we could have DocX check for theunderlineColor
and, if that isn't found, then use theforegroundColor
if it exists. Thoughts?The text was updated successfully, but these errors were encountered: