Transparent Text / problem at 100%

English
#1

I use LO Writer to create EPUBs and PDFs. The user’s reader can change the background color. So, if on a WHITE background I create

this is readable text
this is transparent text << Character property FontColor: WHITE Transparency:100%

and do a print preview the first line is visible the second line is not.

If the user changes to a BLACK background BOTH lines are visible.
This appears to indicate that the “transparency” refers to OPACITY.
Truly transparent would be INDEPENDENT of the background color.

=== Alt #1 aha FontColor: AUTO comes closer

this is readable text
this is transparent text << Character property FontColor: AUTO Transparency:100%
^^ this has the same problem.

=== Alt #2 aha FontColor: AUTO and Transparency: 99% comes even closer

this is readable text
this is transparent text << Character property FontColor: AUTO Transparency: 99%
^^ this WORKS! I compose on white background, text is fundamentally invisible.
^^ print preview on black background, text is fundamentally invisible

Is there a problem with 100% transparency? Or am I doing something wrong?

tia Jonathan

LO version
25.2.7.2 on Win
26.8.0.3 on Linux

#2

Please attach a sample file for analysis.
If your text colour is Automatic, it adjusts by itself to remain visible on any background. You get what you expect only if text colour is manually forced to black instead of Auto.

#3

Thx.
the problem has come down to “Transparency:100%” does not appear to function.
See document attached that contains narrative and screen captures.
The document was created under 26.8.0.3 on Linux

a-lo-transparent_test.odt (52.0 KB)

#4

You make things really difficult but not using styles.
Anyway, you “offending line” in the sample comes at transparency 0%, not 100% as you label it.

I wonder if there is some sort of optimisation behind the scene. *Transparency 100% is kind of nonsensical: the characters are requested to be fully transparent. They should not show, no matter the colour. This there may be a bug in rendering Auto with 100% transparency.

I am afraid there is a misunderstanding about Transparency. Full transparency means the object is not a viewing obstacle to viewing what is behind. Inversely, ful opacity means the object blocks light shining from behind. You have the relation: Opacity = 1 - Transparency. Therefore 75% Transparency equals 25% Opacity. Fundamentally, there is no difference between transparency and opacity. They are only two facets of the same notion.

Entering text as 100% transparency is a corner case.

What is your ultimate goal? Should the change in background reveal different versions of the document? E.g. you have exercices and the answer appears only on black background?
#5

It’s a bug: tdf#144018.

#6

Ultimate goal: Place text that is not visible, yet appears in the index via the concordance.

"Hidden text" is not visible to index generation.

Initially I tried FontColor:Black on a black editing screen worked great until I did a print preview and the black text appeared clearly on the white background. So the process needed to be adaptive and I started with Transparency.

Formatting not always static
Sometimes the formatting of “offending line” CHANGES without my intervention.
I had formatted the text as FontColor:Auto and Transparency:xx
At a later time I select text, Format | Character and find
FontColor has CHANGED to WHITE and Transparency CHANGED to 0%.

To avoid the not(static) problem
I set Heading5 to have the properties I want FontColor:Auto and Transparency:99% and never directly edit the text.

This has the advantage of being able to set Transparency to 44% (the lowest that I can still see) during creation and editing. Then when ready to generate the EPUB or PDF change Heading5 to Transparency:99%. So far that works.

My table of contents generation is for the heading levels 1 to 3 so Heading5 does not appear.

I appreciate your response.

#7

The functionality described is exactly as I saw and limiting transparency to 99% avoids it

Thank you very much! I thought it was something I did. Thanks too for updating the bug list with the workaround. Might save someone else the headache.

CRIKEY - That bug has been around for FIVE YEARS! Reported: 2021-08-23

#8

I understand you use a concordance file to avoid to index individually locations in text. But your “indexation” should be invisible and yet be listed in the Index.

IMHO, you can do it with “standard” index entries (since you explicitly typed the terms, the amount of work is equivalent – only the revamping will cost you).

Where you want a location to be entered in the index:

  1. click somewhere (don’t select text; just click the location)
  2. Insert → TOC & Index → Index Entry
  3. type the term in Entry field
  4. Close

Since no text is selected, the index entry has width zero and does show the key value. No need to try and outsmart Writer with white or invisible key text. Unfortunately, the price to be paid is to enter all occurrences manually instead of using a concordance file. But apparently, you already tagged (“styled”) specifically your entries as Heading 5, so it should be quite easy to find them with Edit → Find & Replace.

1 Like
#9

Yep, tried that then I made the concordance file manually using LO’s ODT. This allows me to see adjacent and related index items without being view restricted to an entry. I can move entries around as I want and not limited.

I also want to see the NotVisible text when looking at the surrounding text. Looking elsewhere is several steps. Thus using Heading5 I have one place to change the Transparancy% for all entries.

As for the work, the document is over a thousand pages and uncounted hundreds of entries.

With the discovery that Transparency 100% is a 5 year old bug and 99% works I think this post is done. Would you concur??

I truly appreciate your responses!

Jonathan

1 Like

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.