Reassigning A is Blocking Legacy Highlighting in many filetypes

[GitHubRulesOK]

SumatraPDF uses A to highlight many different file types such as AZW3 CHM FB2 LOG TXT etc. which many users take advantage of.

It would be best to leave A for such legacy usage and assign Shift Y for yellow to HighlightJump

The reason I suggest Shift Y is that overall it would be easier if Shift R G B Y were a more uniform CAPS LOCK way to set current color in HighlightJump which does not disturb any native usage (other than secondary Go) it also means Shift M could be Magenta and Shift C for Cyan

[nod5]

I have a fix in progress for extensions/filetypes EPUB MOBI CHM TXT LOG.

I notice TXT and LOG aren't on the list https://www.sumatrapdfreader.org/docs/Supported-document-formats.html Do you have quick at hand a list of all filetypes/extensions Prerelease can annotate to a .smx file? (I can look through the source code for that info otherwise.)

It would be best to leave A for such legacy usage and assign Shift Y for yellow to HighlightJump

Disagree. I aim to add the HighlightJump features for every filetype/extension that SumatraPDF Prerelease has .smx annotation support for, and also keep using A for yellow highlight, A (longpress) to cycle color, and so on.

But I'll also make HighlightJump pass A key through to SumatraPDF for any filetype that I haven't yet had time to add and test, e.g. AZW3 and FB2.

[GitHubRulesOK]

There are many complaints that SumatraPDF (and often its experimental highlight) CAN handle almost any type of text file html/zip mime types and a wider range of e-book formats than those allowed for in its list of extensions e.g. .fbz is very common in Eastern Bloc

Just had to exit Jumper so as to highlight a .pdb (I agree many normal users would not still be using such an old format) However I very frequently use OXPS and XPS

[nod5]

Please try updated version. Should now accept EPUB MOBI CHM TXT LOG and should in the case of (so far) unsupported filetypes, for example FB2, pass the key A, E and so on to SumatraPDF. Can you reproduce that?

[GitHubRulesOK]

I tried to use the latest fix but did not seem to work unless I suspend Hotkeys with these highlightable formats some types of nested pdf pages .pdf:# or upto .pdf:#### where # is usually a number .xps .oxps .htm .html AdobeIlustrator (.AI) and with GS loaded .eps or .PS .azw .azw3 .azw4 .fb2 .fb2z .fbz .fb2.zip .prc

[nod5]

I tried to use the latest fix but did not seem to work

New fix in release 2020-02-18. Please try it.

[GitHubRulesOK]

Ok pass-through obviously works I tested a few e.g. an Adobe Illustrator PDF variant, Amazon variant of Mobi, zipped fiction bookV2 and PostScript (see separate comment below)

I press A to see yellow highlight but then need to manually right click to save annotations and can't use D or E like I recollect I used to in both pre-release and full release (possibly some other jump actions may have be enabled too)

SumatraPDF does not annotate eps / ps as such but allowed for .smx as could be built and erased by Highlight Helper

[GitHubRulesOK]

I understand need to test a list of mobi etc. to apply 1.3 scaling but why not let user attempt 1.0 in any other file extension they will soon learn which other types don't work and perhaps raise issues about scaled files to be added to the one list

You could then mention that some file types (such as images, comic books or PS that SumatraPDF will not annotate) will support stored jumps or dots etc. whilst others it may annotate will not store jump locations

P.S images, comic books or PS SumatraPDF can on "Save as" convert them to PDF so they can be annotated

[nod5]

why not let user attempt 1.0 in any other file extension

I want to first get to a point where a set of filetypes works reliably with all the features. Expanding the filetypes later comes later. That said, anyone can right now test if some other filetype works ok with HighlightJump's extra annotation features by adding the filetype extensions to this line in HighlightJump.ahk: vSupportedExtensions := "|pdf|djvu|djv|chm|epub|mobi|txt|log|"

Similarly one can test what happens when the epub scaling step is applied to a filetype by adding it to this line. vEpubExtensions := "|chm|epub|mobi|txt|log|"

Note that in both cases there must be a pipe | character on each side of the extension text.

[GitHubRulesOK]

I seem to have lost a comment recently (must have not pressed send) where having tested version 2020-02-20 I have full red #FF0000 in my settings.txt When I use ARGY they all seem to be that same full red rather than your red green yellow ?

[nod5]

I have full red #FF0000 in my settings.txt When I use ARGY they all seem to be that same full red rather than your red green yellow ?

Added note to Readme that to change the default highlight color to an new hex color code requires edits in both SumatraPDF advanced setting and in HighlightJump.ahk.

[GitHubRulesOK]

Ok we are into issue creep but it is based on legacy expectations

I now see as a result Y key is also bound to SumatraPDF expectation of Yellow Thus I now only have Red and Green since vYellow is my red I had expected that the Default highlight in settings.txt would be over-ridden and substituted by RGBy (and any other colour I may set those to such as CMYK)

[nod5]

I now see as a result Y key is also bound

Yes Y reuses whatever color is set for A, that's a known limitation currently.

[GitHubRulesOK]

In my modified copy I use upercase RGB+CMYK with vSetTxt= #default main problem is the time taken to cycle is about 4 seconds at 500 each

[GitHubRulesOK]

to get around using a cyclic solution for touch use it would be nice to somehow call a color picker without holding a key or blocking two fingure gestures something like this but have not yet worked out how I could best over-ride right click context or set colour to use /show user defined colors without words [edit] ok think I sorted colours out just need to assign Jumper context to Hold RButton with exit to normal context

[nod5]

Are you talking about touchscreen (not touchpad) use? I don't have a Windows device with touchscreen so can't test such use cases unfortunately. But I'll think about adding a color picker popup as optional alternative to the cycle color action.

[GitHubRulesOK]

Yes touchpad and touchscreen users are not well serviced by SumatraPDF as it is highly key orientated, but they are increasingly the ones using a lightweight viewer. I am looking to try and hook icons into the toolbar as was done by Skrommel's "Barnacle" and you also had a 1-4 button concept ( forgot where you posted that) Toolbars need to be visible or floating, my idea is that holding down one finger calls context menu if that has dropdowns for jump forward, jump back, highlight, show GOTO labels, where current filter / highlight is a sub menu dropdown selection then it should avoid the need to call a virtual keypad It is in effect a two button mouse approach without using two buttons together.

[nod5]

I will add a color picker mode for longpress A. First quick prototype looks like this https://imgur.com/a/r6RF2l6

But I won't add other features specifically for touchscreen use, since I don't have or use any such device.

Toolbars need to be visible or floating, my idea is that holding down one finger calls context menu if that has dropdowns for jump forward, jump back, highlight, show GOTO labels, where current filter / highlight is a sub menu dropdown selection then it should avoid the need to call a virtual keypad It is in effect a two button mouse approach without using two buttons together.

Sounds reasonable. Maybe you and others who use touchscreen devices can start up that as a separate tool? Might be worth posting about in the SumatraPDF forum. Such a project could try to be only a touch frontend/UI that under the hood sends key/mouse commands to SumatraPDF, HighlightJump etcetera.

you also had a 1-4 button concept ( forgot where you posted that)

I think I never found a way to make the AutoHotkey child window stick to SumatraPDF during minimize/maximize and certain refresh cases. But maybe there is a way to do it that I didn't think of. But you could probably take over an existing SumatraPDF toolbar button.

[GitHubRulesOK]

Your colour picker looks simple and light that's the sort of result I was aiming for

[GitHubRulesOK]

Inspired by your pop-up I have now got a resizable model that should be able to pick colour with finger and then add that colour or jump up down to same colour

[nod5]

Nice compact layout!

I'm short on time now, but a small tip that might help shorten your AutoHotkey code as you go along. You can call the same label from multiple GUI controls. Example code fragments:

Gui, Add, Text, gColorButtons, M1
Gui, Add, Text, gColorButtons, M2
...
ColorButtons:
  MsgBox % A_GuiControl   ; shows message "M1" or "M2", depending on button press
Return

We can also skip setting any text and instead set associated variables named "M1" and "M2" and the msgbox above will show those names.

Gui, Add, Text, gColorButtons vM1
Gui, Add, Text, gColorButtons vM2

https://www.autohotkey.com/docs/Variables.htm#GuiControl

[GitHubRulesOK]

OK so as not to confuse issues I have opened separate Issue for GUI control and removed work in progress illustrations from comments above.

Back on topic my suggestion is to separate Yellow Colour usage from tied to default A highlight