Upgrade StorageAndroid Bug: Highlight color picker differs from actual highlight color - plus highlight SQL thought
Sometimes I switch between light and dark mode in one session and make highlights of different colors in both modes. I've noticed a bug where the displayed color of the highlighted text can get out of sync with the color picker (the color picker is 'correct' for what is stored in SQL and after exiting reader mode and reopening the PDF, the problem resolves).
https://s3.amazonaws.com/zotero.org/images/forums/u6747210/bet7gxm5ba63fkfb2d3d.jpg
When switching to dark mode, the yellow highlight from the first pic is inverted and shows as blue. This isn't the core issue:
https://s3.amazonaws.com/zotero.org/images/forums/u6747210/6gwunhnxh2d2me4dh63a.jpg
Still in dark mode, I change the highlight color picker to 'blue' which is showing as red (still not the bug being reported):
https://s3.amazonaws.com/zotero.org/images/forums/u6747210/yff5cmfjw4tepx3di3m0.jpg
Finally, switching back to light mode, the highlight whose picker I had changed to 'blue' is now displayed as green. Changing the picker to other colors, several others are also now incorrect. Yellow and red are still correct. This is resolved after exiting the reader.
https://s3.amazonaws.com/zotero.org/images/forums/u6747210/fiph5t63n160gxuk0pld.jpg
A separate but well-depicted similar issue is how highlight colors are depicted in dark mode. Currently, it seems they are inverted, so as we saw, the 'yellow' picker is depicted as blue in dark mode. This is confusing since the color pickers themselves don't change. I've seen some applications that manage to keep the same color hue in both light and dark modes, perhaps only changing the whiteness somewhat. This would be nice for people like me who have a color system where yellow means X, blue means Y, that can work irrespective of light/dark mode.
If this separate issue is considered, it may also be worth considering how highlight color is internally represented. Last I had checked, the SQL table for annotations allowed for a single RGB hex code per highlight, so a highlight is directly tied to an exact shade. With an exact color, users cannot specify a particular shade of blue/yellow that they prefer on their different types of devices and screens (and I've seen dozens of feature requests asking for variations of this). If each annotation were instead to specify a color string, e.g. 'red' or 'color1', then 'red' to one user could mean #FF7F50 in light mode, #8B0000 in dark mode, and for user 2 #DC143C in both modes - decoupling the exact shade from the annotation.
https://s3.amazonaws.com/zotero.org/images/forums/u6747210/bet7gxm5ba63fkfb2d3d.jpg
When switching to dark mode, the yellow highlight from the first pic is inverted and shows as blue. This isn't the core issue:
https://s3.amazonaws.com/zotero.org/images/forums/u6747210/6gwunhnxh2d2me4dh63a.jpg
Still in dark mode, I change the highlight color picker to 'blue' which is showing as red (still not the bug being reported):
https://s3.amazonaws.com/zotero.org/images/forums/u6747210/yff5cmfjw4tepx3di3m0.jpg
Finally, switching back to light mode, the highlight whose picker I had changed to 'blue' is now displayed as green. Changing the picker to other colors, several others are also now incorrect. Yellow and red are still correct. This is resolved after exiting the reader.
https://s3.amazonaws.com/zotero.org/images/forums/u6747210/fiph5t63n160gxuk0pld.jpg
A separate but well-depicted similar issue is how highlight colors are depicted in dark mode. Currently, it seems they are inverted, so as we saw, the 'yellow' picker is depicted as blue in dark mode. This is confusing since the color pickers themselves don't change. I've seen some applications that manage to keep the same color hue in both light and dark modes, perhaps only changing the whiteness somewhat. This would be nice for people like me who have a color system where yellow means X, blue means Y, that can work irrespective of light/dark mode.
If this separate issue is considered, it may also be worth considering how highlight color is internally represented. Last I had checked, the SQL table for annotations allowed for a single RGB hex code per highlight, so a highlight is directly tied to an exact shade. With an exact color, users cannot specify a particular shade of blue/yellow that they prefer on their different types of devices and screens (and I've seen dozens of feature requests asking for variations of this). If each annotation were instead to specify a color string, e.g. 'red' or 'color1', then 'red' to one user could mean #FF7F50 in light mode, #8B0000 in dark mode, and for user 2 #DC143C in both modes - decoupling the exact shade from the annotation.