Default text color of bookmark titles is not restored for export and bookmark generation via text file SOLVED

[rakunavi]

=== UPDATE ===================================================================
The issue reported below has been resolved in Ver 10.4.2 build 390.
I appreciate all the hard work and efforts of the support and development team.
==============================================================================

Hello all,

This comment assumes that the text color is set to something other than black (#000000) by changing to a black theme in the "Customize UI" settings.

In that case, the color of the bookmark title will change when all bookmarks are deleted after exporting them to a text file and then importing them again from a text file (Verified in part A of the attached video). The same issue will occur if the color of the bookmark title is changed to something other than black (#000000) and then changed back to black (#000000) (Verified in part B of the attached video).

I think the color of the bookmark title should match before and after the above change. In Acrobat Reader with the dark gray theme applied, files before and after the change are displayed with the same color.

You can restore the standard colors by applying the default properties from the options menu in the bookmarks pane (Verified in part C of the attached video), but this does not seem to be an essential solution. This is because if you have set the text color to something other than black in the default properties at least once in the past, you cannot restore the standard color in this way.

The screen of the verification process was captured for reference, so please check the attached video for details.
The verification was done after resetting the settings in "Manage Settings".

CapturedVideo.zip

The reproduction procedure is as follows.
The corresponding timecode in the video is also included.
([MM:SS] "MM" shows minutes, and "SS" shows seconds.)

[00:00] - [00:20]
Export all bookmarks to a text file and then delete them. Then import from the text file. Initially all work is done under the standard UI theme. The colors of the bookmark titles are identical to the original files at first glance.

Part A: [00:20] - [00:29]
Change the UI theme to black. You will notice that the colors of the bookmark titles have changed when compared to the original file.

[00:29] - [00:33]
Reopen the file and continue verification.

Part B: [00:33] - [00:45]
Select all bookmark titles, change the colors of them to yellow, and then change to black again.
You will also notice that the colors of the bookmark titles have changed when compared to the original file.

Part C: [00:45] - [00:56]
Select all bookmark titles and apply the default properties from the options menu.
You will notice the colors of the bookmark titles match those of the original file.

Hoping that the above information will be of some help to you.
Thank you so much for your continued support.

Best regards,
rakunavi

- PDF-XChange Editor Plus Version:9.2 build 359.0
- OS Version: Windows 10 Home 21H2 Build 19044.1586
- PC Model: Lenovo IdeaPad C340-15IWL / HP ProDesk 600G1

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you for the report, after some testing, it seems that this issue's cause is unrelated to the dark theme. You are correct that it is only visible in the dark theme once it has happened, but following the same steps in the light theme, saving the document, and re-opening it in the dark theme shows the same issue.
I will forward this to our Dev team for investigation.

Kind regards,

[Toygun]

I think the theme color override the other colors. It should be under. Color-highlighted areas (including search results and selection area highlights) also does not appear properly. So, light-colored bookmarks does not look good in a light theme (and vice versa).

[Daniel - PDF-XChange]

Hello, Toygun

It turns out that this is actually intended, but the Dev team is looking at ways to better reflect these choices.

The way that bookmark color works is a bit unique. In essence, when a bookmark is created, it has 2 separate color flags, one is along the line of "color enabled? [Y/N]" and the other is "Color value [###]". When created, Color is not enabled, and so the theme selected has full control over the color of that bookmarks color. As soon as you assign any value to a bookmark, including black, the "color enabled" option changes to yes, and then the color value kicks in, even if the color is set back to black, color is still enabled, and so instead of ignoring it and showing the opposite, we "fade" the color out to keep it as it is, and while ensuring that the text remains visible within the theme.

I just wanted to offer some explanation of why this is happening for you, do not worry, we do not plan to leave this as it is, some changes are coming that should help with this issue. In the meantime however, I am afraid that I do not have a solution for you.

Kind regards,

[rakunavi]

Hello all, Tracker Support Team and Development Team,

Thank you for taking the time to look into this in detail.
I am relieved to share my situation with you all.
I'm looking forward to future updates.

Best Regards,
rakunavi

[Daniel - PDF-XChange]

[Toygun]

I would like to thank Rakunavi for conveying the issue and Daniel for writing a detailed explanation.

Good luck to the DevTeam.

[Stefan - PDF-XChange]

[rakunavi]

Hello all,

In the Bookmarks pane, hold down Ctrl while dragging and dropping to copy the bookmark. However, I noticed that when the theme is set to black in the Customize UI, the color of the copied bookmark changes unintentionally.

• figure.png
  
  
  Animation.gif

Since the background cause seems to be the same as the one reported at the beginning of the topic, I am reporting it here.

Hoping that the above information will be of some help to you.
Thank you so much for your continued support.

Best regards,
rakunavi

- PDF-XChange Editor Plus Version: 10.3.1 build 387
- OS Version: Windows 11 Home 23H2 Build 22631.4037
- PC Model: Lenovo IdeaPad C340-15IWL, HP All-in-One 22-c0xx

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you for bringing this up once again. It seems the color mode during creation does not matter, only the method of copying the bookmark. doing the same in light mode, save/re-open file and then enable dark mode still has the same faded color. I have brought attention back to this topic for the Dev team again.

[Edit] A proper ticket has been made for the issue this time:
RT#7064: Bug: Bookmark color on copy is incorrect

Kind regards,

[rakunavi]

Hello Daniel, thank you for your reply.

It seems the color mode during creation does not matter, only the method of copying the bookmark. doing the same in light mode, save/re-open file and then enable dark mode still has the same faded color.

I have understood this issue as you describe since the beginning about 2.5 years ago. I hope that Daniel and the developers understood it the same way all along.

Because I have understood the seriousness of this issue from the beginning, I have never used the "Generate Bookmarks From Text File" feature to create bookmarks for a final version of a file, regardless of the color of the UI theme. As I have always said, I have managed to work around the issue by using the free JPdfBookmarks software. I continue to hope for the day when the "Generate Bookmarks From Text File" feature can be used without any restrictions.

Please give my best regards to developers.

Best regards,
rakunavi

[David.P]

Hello all,

I'm not sure if this is related, but I am frequently seeing different colors of bookmarks, at least different shades of gray, without having assigned any other color than the default color (black?) to any of the bookmarks.

I usually resolve this by selecting all bookmarks, assigning some random color to them, and then assigning "black" to all bookmarks again.

Best regards,
David

[Daniel - PDF-XChange]

Hello, David.P

Yes that would be related to this item. It ties into my explanation a few years back.

The way that bookmark color works is a bit unique. In essence, when a bookmark is created, it has 2 separate color flags, one is along the line of "color enabled? [Y/N]" and the other is "Color value [###]". When created, Color is not enabled, and so the theme selected has full control over the color of that bookmarks color. As soon as you assign any value to a bookmark, including black, the "color enabled" option changes to yes, and then the color value kicks in, even if the color is set back to black, color is still enabled, and so instead of ignoring it and showing the opposite, we "fade" the color out to keep it as it is, and while ensuring that the text remains visible within the theme.

It has been brought back up to the Dev team for a review, but at this time that is the most I can offer. It seems that last time this came up, it was lost in transit, so to speak, with numerous higher priority items that came along at the same time.

Kind regards,

[rakunavi]

Hello Daniel and David.P, thank you for your comments.

@Daniel
I had assumed from Stefan's comment the other day that a ticket had already been raised and was in the queue awaiting investigation by the developers, but it seems that the incident handling situation is more complicated than that.

I generally don't post unless I have new information, so I'm glad I happened to drag and drop a bookmark while holding down Ctrl this time and ran into the issue. It is not in my nature to rush people by asking only for the current status of a ticket. If I had the time to do so, I would use it to find new information that has not been reported so far.

Best regards,
rakunavi

[David.P]

Hello Daniel and rakunavi,

Dan, that's interesting, and now of course I understand why unintended color changes of bookmarks seem to happen all the time to me. It might also have to do with me using a dark theme that additionally is heavily customized.

However, I believe this should not be standard behavior because any colors assigned to bookmarks should not depend on a theme a PDF program might be using, but only depend on the actual PDF document itself.

Maybe this can be fixed at some stage in the future.

Best regards,
David

[Daniel - PDF-XChange]

Hello, David.P

The trouble is that by default, the color assigned to bookmarks is black.... which, when viewed in a dark theme, are kind of illegible... Some good examples are the typerwriter tool icon:

image.png

And the Line ending selection options:

image(1).png

If we "left the colors" as is, navigating these menus in dark mode would be problematic. And conversely if we created bookmarks with a default "white" coloring, this would in turn cause the issue for anyone using a light theme. Even if we didn't do this, users make take it upon themselves to manually assign a white text color, leading to the same issue for some readers.

As such, the Editor uses a detection system, if a color is too close to the background theme color, it is intentionally altered to increase contrast, and this is not likely to change.
What is likely to change however, is the bug that these items are being created in a way which forces the "faded grey" coloring in dark mode on certain actions, when the text should remain a crisp white due to using the default "no color assigned" flag.

As an aside, I have created a new ticket on this item:
RT#7064: Bug: Bookmark color on copy is incorrect

Kind regards,

[rakunavi]

Hello all,

I noticed that in build 388, specific color schemes in the UI theme make it very difficult to identify the colors.

Here are the results of comparing Acrobat, PDF-XChange Editor build 387 and build 389 with bookmarks with 16 basic colors in the web colors set while changing the color scheme of the UI theme. Windows theme is the standard setting.

• Basic colors.zip

• Web colors - Basic colors
  https://en.wikipedia.org/wiki/Web_colors

Acrobat: System theme
PDF-XChange Editor: Default (uses system colors)

• figure1.png

Acrobat: Drak gray
PDF-XChange Editor: Black

• figure2.png

Acrobat: Drak gray
PDF-XChange Editor: my custom color scheme

• figure3.png

• Face: #555555
  Text: #FFFFFF
  Selection: #FFFF00
  Window: #555555
  Highlight: #FF6820
  
  
  custom.png

Sadly, in build 389, with my custom color scheme, the bookmark colors are almost indistinguishable. Should I go to an ophthalmologist? I don't want to be greedy, but when I see this I can't help but report it.

I changed the Window from the current #555555 to #444444 for the time being, and the visibility improved somewhat. It seems that the colors of Face and Window should be as far apart as possible.

• figure2.png

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

With the amount of colors there are available to choose from, this is very much a never-ending game of Cat&Mouse

That said, I have passed along this feedback to the Dev team. They are quire busy with other matters at the moment, but this will be on their list in the future.

Kind regards,

[rakunavi]

Hello Daniel, thank you for your reply.

You are absolutely correct. I was merely informing you of one example where the bookmark display color determination algorithm you have incorporated can produce such an extreme result. If this is just noise to the developer, then it should be ignored in favor of doing other important work.

Introduction

• The only issue I want to discuss in this topic is, as I have been insisting since my first post two and a half years ago, that the results are different when you do the following two operations.
  
  
  • Export & import via Bookmarks Export File (*.xcbkm) from the bookmark options menu
  • Export and bookmark generation via text file from the Bookmarks tab
  There have been some improvements in build 388 as shown below, but is it too much to ask for exactly the same results?
  
  I am sure you are already well aware of this, but I will compare the results again, just to show how much of an improvement there was in build 388. Of course, I have read many times the technical background you have explained in the past.
  

  The way that bookmark color works is a bit unique. In essence, when a bookmark is created, it has 2 separate color flags, one is along the line of "color enabled? [Y/N]" and the other is "Color value [###]". When created, Color is not enabled, and so the theme selected has full control over the color of that bookmarks color. As soon as you assign any value to a bookmark, including black, the "color enabled" option changes to yes, and then the color value kicks in, even if the color is set back to black, color is still enabled, and so instead of ignoring it and showing the opposite, we "fade" the color out to keep it as it is, and while ensuring that the text remains visible within the theme.

  The bookmark for the PDF file used in the following verification is really simple, just text entered without changing the text color.
  
  
  • sample.zip
  All settings have been initialized and only the text color has been changed to white (#FFFFFF) after selecting black as the UI theme.
  
  
  • figure1.png
  It may not be necessary to explain, but each of the operations described above is shown in the following video.
  
  
  • Animation1.gif
    
    
    Animation2.gif
  The Hex color code is shown in the figure, which is the result of color detection of the captured image using the picker function of another image software. In no way is that value set to the bookmark. Again, the text color of the bookmark is not changed at all in the sample file.

In case the Text color in the Preferences Dialog is #FFFFFF

• The following verification shows the results of build 387 and build 389, respectively, with the figure divided into three parts from left to right.
  
  
  • Left side is the original "sample.pdf"
  • Middle is the result of export and import via Bookmarks Export File (*.xcbkm)
  • Right side is the result of export and bookmark generation via text file
  • figure3.png
  The results for build 387 are as follows
  
  
  • 1_build387_white.png
  The results for build 389 are as follows
  
  
  • 2_build389_white.png
  As you can see, build 389 improve the results of export and import via text file from #8D8D8D to #B9B9B9. Of course, the color code changes somewhat depending on the theme color scheme, but the improvement in build 388 is by no means #FFFFFF. On the other hand, exporting and importing via the Bookmarks Export File (*.xcbkm) always restores #FFFFFF, regardless of the build.

In case the Text color in the Preferences Dialog is #00FF00

• An extreme example is shown below for reference. Now change the text color to green (#00FF00) in the UI theme. Of course, I am not changing the color of the bookmarks.
  
  The result of build 387 is as follows.
  
  
  • 3_build387_green.png
  The result in build 389 is as follows.
  
  
  • 4_build389_green.png
  Exporting and importing via Bookmarks Export File (*.xcbkm) restores the original bookmarks exactly as they were, so #00FF00 is always displayed regardless of the build. In contrast, the result of exporting and importing via text file is not affected by the text color change in the UI theme. In other words, exporting and importing via text file cannot have exactly the same results as exporting and importing via Bookmarks Export File (*.xcbkm).

Closing Remarks

• On the occasion of this posting, the title of this topic has been revised as follows. It seems to me that this title more accurately describes the issue.
  
  
  • (Before) The standard color of bookmark titles cannot be restored when the dark theme is applied.
  • (After) Default text color of bookmark titles is not restored for export and bookmark generation via text file
  The above is exactly the same information as in my very first post, but explained in a different way. As I have repeatedly mentioned, JPdfBookmarks, a free software, can restore exactly the same bookmarks even when exporting and importing via a text file. There is no color problem.
  
  
  • https://sourceforge.net/projects/jpdfbookmarks/
  When exporting and importing bookmarks, is it really that difficult to make sure that the final restored bookmarks are the same regardless of whether you use a Bookmarks Export File (*.xcbkm) or a text file? Is it too much to ask? I've been thinking about it, but I can't help but wonder.
  
  Am I being quite stupid or is there a XY problem?
  
  
  • XY problem
    https://en.wikipedia.org/wiki/XY_problem

Thank you for taking the time to read this message.

Best regards,
rakunavi

- PDF-XChange Editor Plus Version: 10.4.1 build 389
- OS Version: Windows 11 Home 23H2 Build 22631.4169
- PC Model: Lenovo IdeaPad C340-15IWL, HP All-in-One 22-c0xx

[Paul - PDF-XChange]

Hi, rakunavi

the devs say they will do what they can for the next build.

Thanks again for the feedback.

[rakunavi]

Hello Paul, thank you for your reply.

I am glad you shared my situation. It looks like you are finally making progress in resolving the issue.

Perhaps the reason for the delay in handling this issue within Tracker is that I reported two issues together in my opening post.

• The first is the issue I raised in my opening post as (Verified in part A of the attached video) and (Verified in part C of the attached video) and which I most wanted to insist on.
• The second is the issue I raised in my opening post as (Verified in part B of the attached video), and which I wanted to argue as an extra.

Perhaps only this second issue, B, has attracted attention, and the first issue, A&C, has been overlooked. After that, I tried many times to get people to focus on the first A&C issue again by referring to this topic from other topics, but to no avail. This time, I am glad that my last-ditch effort to report only on the A&C issue was unexpectedly successful.

Communication does not end when you have conveyed your message properly, but it is meaningful only when it is conveyed 100% to the other party. In that sense, there is still room for improvement in my report. I regret that two and a half years have been wasted, and I would like to continue to make efforts to deliver reports that are easy for others to understand.

Please give my best regards to the developer.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

I cannot deny there was some misunderstanding with the original post. Nonetheless, I am glad we have made it to the point of clarity on this now. I should warn than Vasyl, and the rest of the UI team are quite busy at this time, so as much as I would like to say this wont go on much longer, I still cannot promise a swift turnaround on this item.

Kind regards,

[David.P]

Hello all, I just was going to add that for me, the new bookmark colors are also way too pale:

bookmark colors before and after.png

Click to view animation

Thanks very much for looking into this.
Best regards,
David

[Daniel - PDF-XChange]

Hello, David.P

Thank you, yes this is being looked at. Hopefully we can see more impactful colors in the future, with fading only occurring on those which have a problematic level of contrast.

Kind regards,

[RMan]

If I may make a suggestion I think I've made in the past is to just always have the bookmarks pane background white. Or add in a setting and a checkbox for "Do not apply window color to bookmarks pane" or "Do not apply window color to bookmarks pane when colored bookmarks are used"

The first one you always have the bookmarks pane background white. That way no matter what theme or window color you use the bookmarks are always shown in the exact color they were created in. You never have a conflict.

The second one you just switch it to white if a bookmark is found with a color other than black or if someone changes the color property of one. 95% of the time the bookmarks pane would be the theme background because the bookmarks are always assigned as black. But the few that have a bookmark other than black again it displays it with white background and the text as the color they are assigned so you never have a conflict.

The PDF itself is typically a white background and the bookmarks are basically the Table of Contents so I don't think too many users would mind if it was white by default.

[David.P]

The argumentation is as good as the proposed solution. I like it!

[Daniel - PDF-XChange]

Hello,

Another good suggestion, I cannot make any promises, but the Dev team will see this when they are looking at it next.

Kind regards,