Created attachment 125096 [details]
PNG image depicts screenshots exemplifying the bugs

Replace previous illustration by better version

(In reply to kurt.pfeifle from comment #0)
>    2. Extract ODS source from PDF (you should know how to do this) and
>       open it in LO.

I don't know how to extract it. Please tell us how to do it or better yet, attach the original ODS.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information/document.

@Kurt : as mentioned in comment 4, please simply provide the source ODS document. It is doubtful that anyone from QA is going to jump through hoops trying to extract an ODS document from a hybrid PDF for an alleged transparency/incorrect font display problem.

Note that transparency support of images when exporting to PDF/A does not appear to be possible, cf. bug 59271.

Also see bug 62728 re support for PDF/A-2 (transparency support)

In response to comment #9...

(Sorry, due to being handicapped by long illness, I lost track of this bug for too long.)

I can confirm, that this bug is still hitting me, currently with LO v5.4.2.2 updated just now.

The "weirdness" of the print preview is still there, even though it expresses itself in a slightly different way. (I'll provide new screenshots in a minute...)

Regarding the different sub-points of comment #9:

ad a):
  Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4
  CPU threads: 8;
  OS: Mac OS X 10.12.6;
  UI render: default; 
  Locale: de-DE (en_US.UTF-8);
  Calc: group

ad b):
  Steps are already provided in the original bug report.
  Steps to extract the original ODS from attached Hybrid PDF will follow
  in my next comment.

ad c):
  Test case was already provided with original bug report.

ad d):
  Screenshot (PNG) already provided with original bug report.

ad e):
  I did read all comments (again) and will respond to some in my own 
  next comment(s).

Created attachment 137210 [details]
Side by side comparison of: (1) original document view (left); (2) PDF or print output (center); (3) print preview (right)

Side by side comparison of:
 (1) original document view (left);
 (2) PDF or print output (center);
 (3) print preview (right).

The new attachment (2017-10-22 18:25 UTC) is made from screenshots as side-by-side view of:
 - document view (left)
 - PDF or print output (center)
 - print preview (right)

Note how the headline font of this page:
 - shows up in document view as BLACK,
 - even though it is defined in YELLOW.

Further note how for the chart in the bottom third:
 - document view is largely correct
 - PDF or print output is largely correct
 - but print preview shows a weird artifact (table as background of the chart).

Re. comment #4 and comment #5:

Sorry for wrongly assuming that ODF people/developers who think they are knowledgeable enough to evaluate bug reports which concern LibreOffice features would know how one of its nicest features (creating and handling its own non-standard invention, "Hybrid PDFs") works...

My bad, mea culpa.  :-(   Please forgive me.

I created this file as a Hybrid PDF, because it has the following advantages:

1. It directly shows the different look of the printouts and PDFs.
2. It embeds in the same file the original ODS document which demonstrates the bug.
3. You can extract the original ODS document to reproduce the bug itself.

----

Ok, here is a step-by-step recipe to extract the original ODS file from the hybrid PDF:

1. Open the PDF with a text editor -- but please use one which does handle binary
   files gracefully. Use `vim -b`, for example. When using VIm, switch on the line 
   numbering by typing `:set numbers` in VIm's command mode.

2. Jump to the very end of the file. (Type ":6708" if you are using VIm to jump to
   line 6708.)

3. You should see the following PDF trailer code in lines 6702 - 6710:

       trailer
       <</Size 488/Root 486 0 R
       /Info 487 0 R
       /ID [ <BD60A3189BDF9102C9822623D7BA3CEF>
       <BD60A3189BDF9102C9822623D7BA3CEF> ]
       /DocChecksum /63B562B0B0FD347C6E1B587CE587A9BF
       /AdditionalStreams [/application#2Fvnd#2Eoasis#2Eopendocument#2Espreadsheet 461 0 R
       ]
       >>
   
4. Line 6708 tells us that the ODS document is embedded into the PDF as object 
   number 461.

5. Go to object number 461 (search for the string "461 0 obj" with the help of
   your text editor).

6. Locate this string on line 5359.

7. Locate the keyword "stream" two lines below, on line 5361.

8. Delete all the lines before and including line 5361. What remains is the line
   starting with the two letters "PK", and all the lines until the rest of the
   file.
   
9. Now search for the string "462 0 obj". You should find it on the (now new)
   line number 433. (You  H A V E  deleted the lines from the beginning of the
   file up to and including line 5361, have you?)
   
10. Locate the keyword "endstream" on (now new) line number 430.

11. Delete all the lines from 430 through to the very end of the file.

12. Save this file under a new name, say "original.ods".

Voila!, you now have extracted the original ODS file from the Hybrid PDF created 
by LibreOffice.

I repeat: it is very important to use a text editor which is able to handle binary 
files! Otherwise this will not work as described.

----

Another thing:

   1. If you download the Hybrid PDF file, make sure you get the original version. 
      Check that the file size is 299.252 Bytes.

   2. Should you open it in, say Chrome's previewer and save it from there, then
      the file size may be ca. 130 kByte smaller. This is due to the fact, that
      OO/LO did not implement its "Hybrid PDF" by using the standard method to
      embed other files into a PDF, but invented its own "proprietary" method
      which Chrome/PDFium does not seem to be able to handle...

P.S.: You may also want to look at bug95328 with comments (esp. after https://bugs.documentfoundation.org/show_bug.cgi?id=95328#c3)

Well it won't be me I'm afraid. 

I don't see why I should have to jump through hoops of using a particular text editor to download a PDF that I shouldn't preview with a particular browser extension and then open it in a specific text editor that handles binary information in a certain way, edit the PDF from within the binary editor and save the remaining information to a new file, when you could just provide a sample ODS that displays the problem about which you are reporting.

In fact, I've no doubt that the detailed explanation and steps you gave, although no doubt perfectly acceptable for someone of your skills, are not for a volunteer like myself just trying to reproduce the allegedly erroneous behaviour who only understands how to load a ODS document into LO and look at it to see whether or not the problem can be reproduced.

No doubt also that the description you wrote, while highly interesting, took you longer to write and submit than to create a test ODS document and upload it to the bug report.

Setting back to NEEDINFO with a request for a test ODS document that is alleged to show the problem being reported, i.e. colour fidelity deficiency of a headline.

(In reply to Alex Thurgood from comment #14)
> Well it won't be me I'm afraid. 
> 
> I don't see why I should have to jump through hoops 

Don't proudly volunteer to evaluate bug reports for LO then?

[...]

> when you could just
> provide a sample ODS that displays the problem about which you are reporting.

The ODS is embedded by LibreOffice in the PDF file.

And you don't know how to extract it again with the help of LibreOffice?!?
Come on...

[...]

> Setting back to NEEDINFO with a request for a test ODS document that is
> alleged to show the problem being reported, i.e. colour fidelity deficiency
> of a headline.

Did you read my report f u l l y?
Didn't I mention "two different bugs"?
Did you look at the screenshots?
Did you see that these  N O T  O N L Y  show some "colour fidelity definciency"?
Didn't I mention how removing transparency makes the bugs go away?
What can I do to make it better understandable?

Tested on 

Version: 5.4.1.2
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
Threads CPU : 8; OS : Mac OS X 10.12.6; UI Render : par défaut; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group



So, this is what the instructions to reproduce should have mentioned :


1) Drag and drop the PDF attached to the bug report on a running instance of LibreOffice.

2) The ODS file embedded in the hybrid PDF opens in Calc.

3) Look at the Title cells on the sheet named VfB Statistics (last 10 years) - note how the cell has a red background and black text characters.

4) A right mouse button click on cell F1 shows the text to be yellow (Yellow2 in the LO colour palette) on a Red4 background.

5) Compare that render with the rendering of the PDF file opened in a PDF viewer application, for example Apple's Preview.app or Adobe Reader. Note how the same text in the heading is yellow.

CONFIRMING the display bug.


Please open a separate report for the transparency issue.

Since one bug handler alreay dis-volunteered to further process this issue and took it out of the active loop by setting it on NEEDINFO, here is another method to get to the original ODS file embedded in the attached Hybrid PDF:

1. Open the Hybrid PDF with LibreOffice.

2. Save it again -- but use "Save as..." + select file type "ODF Spreadsheet (ods)".
   (If that is too much "jumping through loops" for you, then don't further touch
   this bug. Don't change its status either.)

3. Your newly saved file has now gotten rid of the outer PDF shell and is an ODS
   file again.

I really, really wonder why people here do not know such basics of LO usage....

Bug still present with my current LibreOffice/Calc version:

    Version: 5.4.2.2
   Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4
CPU threads: 8;
         OS: Mac OS X 10.12.6;
  UI render: default; 
     Locale: de-DE (en_US.UTF-8);
       Calc: group

(In reply to kurt.pfeifle from comment #15)
> (In reply to Alex Thurgood from comment #14)
> > I don't see why I should have to jump through hoops 
> 
> Don't proudly volunteer to evaluate bug reports for LO then?

Kurt: it is beyond me, why you don't see the unsustainable nature of what you are proposing. LibreOffice has thousands of features. No single volunteer or paid worker can be expected to know every single one.

Read this carefully: https://wiki.documentfoundation.org/QA/BugReport#Good_Reports
The exact topic is mentioned under "Less Good Reports": "Do not assume contributors know what you're talking about."

This just FYI, please don't continue by replying to this.

(In reply to Buovjaga from comment #19)
[....]
> This just FYI, please don't continue by replying to this.

Ok, I'll let it rest now. Peace!

Wow, this was some condescending bug report :)

Anyways, still present.

In fact, the issue with the font color is also present on Windows.

The print preview on macOS has some issues with the tables (nowhere near as bad as the screenshot), but produce at least a correct PDF

-> I'm making this an OS all issue. Please report a new bug for the table print preview rendering (one bug report should only contain one issue)

I'll upload the extracted ODS file

Version: 6.4.0.3 (x64)
Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8
CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

Created attachment 160573 [details]
ODS test case

Convoluted description for a bug: in attached ODS any font color wrongly appears as automatic, proper color is only seen in cell edit mode.