Text color styling in rich text editor not applying in PDF

[bwallis42]

We have a form with a rich text editor in it (Orbeon 2017.2) in which some of
the text in a form is colored. When we generate a PDF file from that form
the text comes out in black and the background white regardless of the
setting in the editor. Font and font size also comes out somewhat
differently.

Here is the web form view

<http://discuss.orbeon.com/file/t375137/view.jpg>

and this is the PDF output of the same control in the form

<http://discuss.orbeon.com/file/t375137/pdf.jpg>

any ideas how I can get this to work?

--
Sent from: http://discuss.orbeon.com/

[Erik Bruchez]

Brian,

Since the input of the PDF processor is based on the "view" mode, check the
HTML which is produced in view mode in that case. I am not sure whether the
rich text editor produces `class`, or `font` or other elements. But checking
that might be a good start.

-Erik

[bwallis42]

Sigh.

I got to the base of this. It is bootstrap.css that does it and it is done
intentionally. See this article
<https://stackoverflow.com/questions/33410724/bootstrap-print-css-removes-background-color>
for a bit of an overview of why.

TinyMCE (old and new versions) insert inline styling for font color or
background color changes like this


That should beat just about all css trying to override it except... Buried
inside bootstrap is the following



So the '!important' wins the day and the font color is black.

Now I don't want to try to muck with the internals of an orbeon release and
i can't see anyway to override this.

If you are generating the bootstrap.css that is used in Orbeon you could
generate it with the print styles omitted (untick "Print media styles" at
https://getbootstrap.com/docs/3.3/customize/)

Was it intentional to include these print styles in orbeon when you changed
to using bootstrap.css?

Versions prior to that (3.9 at least) did include the font colors of the
rich text editor in the generated PDF files so this is a regression of
sorts.

[bwallis42]

Hi Erik,
Any ideas about this issue? As far as I can tell it is a bootstrap.css
issue and could be changed in orbeon.

It would be nice to have the PDF output match the screen view of the form
but the reasons why not discussed in the referenced article are also
reasonable.

This also applies to any other colors set by css, say on all the labels in a
form, etc.

thanks
brian...

[bwallis42]

Hi again,
Just wondering if you have an opinion on this. If the current behaviour
(pdfs only supporting b&w) is what orbeon will support going forward then I
just need to know this. If you would consider changing this behaviour to
support colour in PDF files that would be great.

[Alessandro Vernet]

Hi Brian,

I imagine that we're just using the default Bootstrap, which if no changes
are done includes the print styles that are causing you all this grief. Have
you tried generating a PDF with a version of Bootstrap without the "Print
media styles"? Doesn't it break other things in the PDF? If not, we could
indeed not include those styles.

Another thought about the `!important`: have you tried overriding it by also
using an `!important` in your own CSS?

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Hi Alex,
I can't "out important" it. The way the code gets structured, the css from
bootstrap in the @media print always wins, overriding any attempt by me to
override it. The big problem with important, it is like bringing a gun to a
knife fight :-)

I would need to do a rebuild of the war to replace it with a later version
of bootstrap with the media print disabled. Bootstrap has moved on two
major releases since the version 2 you have and they no longer have the
generator for version 2 online. I've generated one from version 3 but with
it being a major version change I'm likely to cause other issues as well.

I'm going to leave it for the moment, other more pressing issues to work on.

Do you have the json config file that the bootstrap generator creates? It
would be a better place to start from if you changed any of the
configuration options when it was generated.

thanks
brian...

[Alessandro Vernet]

Hi Brian,

I love your analogy, but it should still be possible to override the
`!important` by you bringing both a gun and a knife to the party. (I'm not
sure the analogy holds in the real world, and wouldn't want to try, but
hopefully trying with CSS is safer!). Also see:

https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity#How_to_override_!important

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Hi Alex, Thanks for that. I was unaware that specificity still applied when
rules were marked as important. In this business you really do learn
something new everyday!

I'll give that a try.

[Alessandro Vernet]

Got it Brian, you'll let me know know how it works out.

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

Unfortunately on investigation, I cannot get this to work.

The problem is that I can use some CSS to override the bootstrap @media
print CSS as suggested but the CSS that produces the color in existing forms
is not that CSS.

There is no way that I can find with some additional common CSS to override
the bootstrap @media print CSS to make it revert back to the previous
setting.

So to override the bootstrap CSS I would need to find and change every
existing form's css specifications for the various elements that have been
styled. Not a very practical idea I'm afraid.

We create our own war file from the distributed war file with a different
web.xml file and some additional classes for authentication (login module).
I was wondering if there might be a way I could put my own css file (a copy
of bootstrap.css) somewhere in our war file that would override the one
found inside orbeon.

thanks
brian...

[Alessandro Vernet]

Hi Brian,

Mmh… yes, I see. Which takes us back to your initial idea of changing the
Bootstrap CSS. I'm fine doing this, a priori. I'm not sure if we talked
about this, but is this something that you've already tried doing on your
side, recompiling Orbeon Forms?

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[bwallis42]

I can certainly rebuild orbeon on our side but it would be the CE version and
I can't do that in the long term anyway. Our integration with version 3.9
included various changes we made inside the orbeon source and is the reason
we ended up taking so long to upgrade to version 4.

It made incorporating updates to orbeon next to impossible. We aren't going
down that track again :-)

So, I have tried this with a simple change by modifying the bootstrap.css
and bootstrap-min.css files in orbeon-form-runner.jar, i found the correct
ones in apps/fr/style/bootstrap/css.

The change we want is to just remove the (text) color setting, i.e.

@media print {
.orbeon * {
color: #000 !important;
text-shadow: none !important;
background: transparent !important;
box-shadow: none !important;
}

becomes

@media print {
.orbeon * {
text-shadow: none !important;
background: transparent !important;
box-shadow: none !important;
}

This gives us what we want (actually, I'm not sure this is "correct" but it
is what the customers want :-)

Can you think of a way I can do this without rebuilding orbeon? How are the
css files loaded out of the jar file when requested and could I override
this by putting in a different jar file or files somewhere within the war
file?

I could write a step in our assembly build that extracts the files, changes
them and puts them back into the orbeon-form-runner.jar but that is a pretty
fragile build step.

thanks
brian...

[Alessandro Vernet]

Got it Brian, I'll look into it to see if we can remove this out the
Bootstrap CSS we ship out-of-the-box, and will follow-up here once I know
more.

Alex

-----
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

[Alessandro Vernet]

Hi Brian,

Here are the results of my investigation on this one.

One strategy consists in removing the `!important`, so the inline
`style="…"` produced by the TinyMCE will take precedence over our rules for
print removing, say, colors. The problem is that we need to have a selector
with a higher specificity than anything we have in Bootstrap or Orbeon
Forms. There are a lot of rules, some with lots of classes. I tried but
found it very hard to come up with a rule that is stronger. It comes down to
having a number of selectors, many with lots of classes, targeting different
parts of the document. This is time consuming, error prone, and poses a
maintenance problem, in the sense that rules that work today can easily
break in the future as CSS is changed or added to the product.

The other strategy is to keep the `!important`. But then, we need to find a
rule that doesn't target elements inside the TinyMCE. It would be a piece of
cake in XPath, which has an ancestor axis, but I couldn't find a reasonable
way to do this in CSS.

So, unless you have other ideas, I'm afraid that the print output will have
to stay black and white.

-Alex

[Erik Bruchez]

As a follow-up to this thread, we have added the following issue:

https://github.com/orbeon/orbeon-forms/issues/4158

-Erik