Foxit style highlighters

[David.P]

with me to bring this up one more time, but a topic being closed with no opportunity for discussion is something I've not seen much, if any, on the forum before (and I've been around for a while).

It was a very deliberate change that required a very large amount of requests before the Dev team would agree to make it in the first place, it will require an order of magnitude more demand for them to even consider undoing the change after the work that was put in already.

[Emphasis added]

I wonder where this large amount of requests can be found. Apparently not here in the forums, since to my knowledge, there are only these few threads about it:

https://forum.pdf-xchange.com/viewtopic ... 2A#p152044
https://forum.pdf-xchange.com/viewtopic ... 2A#p160166
https://forum.pdf-xchange.com/viewtopic ... 2A#p144159
https://forum.pdf-xchange.com/viewtopic ... %2A#p95194

At least one of the users who requested this change, I'd suspect more than one, came from F0xit Reader. Unfortunately however, Fxit is a traditionally rather awful PDF software that can't even begin to hold a candle to PDF-XChange Editor.

Foxit thus can't really make much of a starting place to look for improvements to PDF-XChange Editor.

Here is the promised screenshot showing why I believe this change was an unfortunate decision, and why it made a lot of sense that PDF highlights have had rounded ends for decades. Also, they still do, with Ad0be Arcr0bat.

Sample document with text shading and PDF highlighting Classic vs. 'Foxit Style'.pdf

(578.73 KiB) Downloaded 46 times

As can be seen from this example, one of the reasons why the rounded ends of PDF text highlighters are formed such because then you can immediately tell at a glance and from a distance that this is a PDF comment element -- and not just text shading that was already present in the original document.

Now with the rectangular highlights, it is impossible to quickly see which highlights are comments and which are not.

Therefore, I consider this change to be very unfortunate. It will lead to permanent significant downsides at least in my daily use case of PDF-XChange Editor.

Again, apologies for pestering the Tracker Team again with this issue.

Please, consider reverting this unfortunate change.

Kind regards
David

[Willy Van Nuffel]

Hello,

I can understand that Tracker Software Support and Development are not always pleased with repeating questions for continuously changing things in one way or another. I suppose they are thinking "you must finally know what you want" and so are deciding to put the concerning topic(s) to the "Locked" status.
https://forum.pdf-xchange.com/viewtopic.php?p=160634

That is why I would NOT opt for reverting to rounded corners for the highlight tool, but rather go for a 'choice' between straight and rounded corners, in the same way that you can choose between straight and smart quotes in Microsoft Word. The necessary code for both options already exists, it is only a question to offer a choice between the two of them, i.e. a parameter in the Commenting options in Preferences.

@Tracker Software
Do you agree with me to make everybody happy?
In either case, thanks for the continuous effort.

Kind regards.

Willy

[David.P]

Hello Willy & Tracker Team,

Of course, I would be perfectly happy with this solution.

I believe that this would apply as well to many other users who frequently annotate PDF documents that already contain various text background shading, as shown for example in the above screenshot.

Thanks @all
David

[TrackerSupp-Daniel]

Hi guys,

Thank you for the input, the previous topic was indeed closed to finalize that discussion, the decision has been made and for now will not be seeing change. I understand the view of asking for an option to choose, but the are countless hundreds of functions we offer that could have similar options implemented, if we were to offer an "A or B" option somewhere for all of them, the application would become a bloated mess that is barely usable.

It is nice to please everyone when we can, but sometimes it simply is not possible without going against the intended use of the software, and bloating the feature set. This is very much the same reason that we are very hesitant to add any additional features to the "search" pane, as I know you have had some interest in already David. That is one area of the software that has already reached critical mass, and is without a doubt, something that will become far more convoluted to use if we try to add any new features to it.

In this case, as I mentioned in the other topic, there was extreme demand for these items, yes, some of our users contact us on these forums and you are able to search for some of the conversations, but to be honest, the Forums are the least busy method of communication we have. Our resellers and larger clients typically contact us via email or through our livechat, a system you cannot see; trust me when I say that I have seen dozens of requests for this myself (my colleagues have seen more), in some cases from clients that hold some of our corporate world licenses (with hundreds of thousands of individual users in their corporation requesting this change).

For some added finality, I brought this topic to our Lead Developer for his review and had a discussion, he confirmed that we will not be adding to feature bloat by giving an option here. For the time being, for better or worse, this feature is locked in place.

Kind regards,

[igorlima]

Hi all!

I never used Foxit, but the new highlights with flat corners are definitely a step forward, specially aesthetically wise.

Before, the highlight would always surpass the selection and affect elements not meant to be highlighted like punctuation and spaces before and after the word.

version 9.2.359.0

ezgif.com-gif-maker.gif (4.12 KiB) Viewed 3201 times

version 9.3.361.0

ezgif.com-gif-maker (1).gif (4.49 KiB) Viewed 3201 times

Thank you very much for this improvement, Tracker Team!

[TrackerSupp-Daniel]

[Arnold]

I created a searchable document with 9.3.361 using Enhanced OCR and the highlighting of periods at the end of sentences was inconsistent. I don't remember this happening with previous versions. I emailed the files over for you guys to take a look at. Maybe just this document or "user error".

Thank you.

[TrackerSupp-Daniel]

Hello, Arnold

I do not see the same issue in the files you sent us, as you can see, the marked spot from your screenshot appears correctly on my end? did you make further changes to this file since you reported this?

Though I do see that my colleagues Paul has forwarded them to the Dev team for further investigation, I wanted to offer my own investigation here in the meantime. From what I can see, the only differences are minute details like the assumed font size and relative position of each text object, as an example, I have converted the searchable text into visible text overlaying the original, and given them a color which stands out, as you see, with tthe ABBYY version, the text in the areas where you marked is actually a bit short from the full size of the visible line of text, which can cause minor differences in highlight placement:

Meanwhile, If you look at the version which I applied our EOCR to generate invisible text, you will see that the text in those same areas is actually a bit longer then the original text is, coving more area, meanwhile, in the second section, the woth "but" at the end of the line has the opposite issue, and the highlight does not cover it in full.

In both of these cases, this is a minor blemish caused by discrepancies in how OCR works, Unfortunately there is little we can do to rectify this, as that calculation is primarily left to the OCR engine. In our case, we use an older version of ABBYY's engine (I believe version 12 or 13 now) while ABBYY's own transformer should, if updated, be using their latest version which is a few versions beyond what we are on, and still encounters the same issue.

Perhaps the Devs will get back to us and offer some information that says otherwise, but I expect that this will be something that "simply is" about OCR in general, and is something you will run into from time to time with all OCR engines.

Kind regards,

[Arnold]

Pretty sure they are using the same engine which is version 12. PDF Transformer is discontinued and uses an older version.

[TrackerSupp-Daniel]

Hello, Arnold

Indeed you are very much correct (my mistake), but with that it is even more expected that we see very similar handling in this specific situation. I am unsure if the later versions have improved this very much, but I can say that at the moment, it is unlikely we will be moving to a newer version of the OCR engine, at least until some distinct feature which absolutely need to offer arrives.

Kind regards,

[Arnold]

I made no changes to any of the files. You have the actual searchable files highlighted only by PDFX but created by ABBYY and PDFX using the same #12 engine. I will view these files on my other computers for comparison.

I have now taken those two searchable files, erased the highlighting created by PDFX, and re-highlighted them using ABBYY. Same thing. Please see screenshots. I emailed those 2 files to you also. The top screenshot is the PDFX file

Time permitting I will try to do the same process of OCR and highlighting with versions 7 & 8 using the same original graphics only file. The rounded nature of the highlighting may well hide the missing periods at the end of the 2 sentences though.

Thank you.

[Arnold]

I emailed version 7 & 8 OCR'd and Highlighted files over. Version 7 appears to be the most accurate even though it has no "Enhanced OCR" capabilities. Screenshot below.

Makes me believe I was remembering version 7 highlighting when this caught my attention. I was still using version 7 long after everyone else had switched to version 8 because I was stuck using Windows XP for years!

Nearly every pdf file that comes my way these days does not require OCR, so this does not show up.

Thank you.

[TrackerSupp-Daniel]

Hello, Arnold

If you are that set on continuing to use the V7 OCR, we still offer the tesseract engine within the Editor, there have been minimal changes to it (essentially only updates in regard to where we store the language files), and some minor bugfixes since back then, so it should work nearly the same for you. You can change the OCR engine in use at any time from the prefereences (Ctrl+K) under OCR.

Kind regards,

[Arnold]

Everything I originally sent in was using the latest version. I sent you the version 7 & 8 files for comparison only. Everything you have seen until those last files I sent you was strictly version 9, specifically 9.3.361.0. That is the only version I use.

For the life of me I don't understand how anyone got the idea that I was suggesting anything needs to be done with versions 7 & 8. This was never, ever about prior versions.

I will say though that the highlighting in version 7 makes the highlighting in version 9.3.361 look sloppy by comparison. I was pretty sure that was the case so I went back and checked. Just compare the 2 files. It is very easy to see. The highlighting in version 7 looks more professional.

Thank you.

[TrackerSupp-Daniel]

Hello, Arnold

I did not think that you were suggesting anything needs to change in the older versions, I am honestly a bit confused as to how you reached the conclusion that I thought as much. I was simply saying that if the V7 tesseract OCR engine gives you the desired result, it is still available in V9.

As it stands, the only issue I see still being discussed here is that on occasion, OCR can create searchable text that is a bit longer or shorter than the original "text" in the image was, resulting in some minor appearance blemishes with certain tools.

For clarity going forward, Arnold, if there is any more, can I ask you to please send a new email, detailing those items, mentioning me personally, with a link to this forum post, so that I can collect that whole topic as a single item, and we can leave this forum topic as it is no longer a particularly relevant topic of discussion.

Kind regards,

[David.P]

Hi all,

there is a related discussion here that shows further non-favorable side effects of the new highlight design, see also #2, #3 and #4 in the screenshot and attachment:

A Small Suggestion about Highlighting and Copying

Best regards,
David

Text Selection with Highlights and Links.pdf

(15.39 KiB) Downloaded 25 times

[TrackerSupp-Daniel]

Hello, David.P

I have addressed the latter issue you mentioned with the following ticket over in that other thread:
RT#6689: FR: Add "alt-object-cycle selection" to commenting tools.
While I cannot offer a timeline, I do help we can implement this to help out with these issues.
Beyond the selection, I am afraid that as before, we still do not have plans to make further changes to the appearance of the highlighters. These were altered to look like this due to overwhelming user demand, and as such, will be staying for the foreseeable future.
As for the underlining position issue, are you possibly using an older build? If you are using colors which are too similar, yes, they could indeed be difficult to see, but in the current release, the highlight box does appear farther out than the underline itself:

The exact positions of both are based on a few font metrics, so it is possible that a small handful of fonts could show the issue your image presents, but I could not reproduce it with the majority of common fonts.

Kind regards,

[David.P]

Thank you, Dan.

I hope that there is room for improvement regarding the selection behavior of superimposed links and highlights.

Today I had the usual difficulties selecting highlights in order to add comment text to them, because links were also attached to the same text.

Your observation about the underline being in a different place than the bottom of the highlight is correct. My observation was indeed about the position of the underline of links being in the same place as the lower edge of the highlight.

In fact, links that are created on some text selection will have exactly the same size, or bounding box, as highlights that are created on that text. This is also the reason why highlights are very difficult to select when a link has been applied to the same text:

Links and highlights having the same bounding box

Thank you for the commitment and for creating the ticket.

Best regards
David

[TrackerSupp-Daniel]

Hello, David.P

AHA! I see, the underline present when the link object box is specified to have an underline, that would explain the difference in what I saw. I will pass that along to the team to see what can be done there. As for the selection woes... I cannot promise much there, but we will look into it.

[A quick addendum: In the meantime, you could make the border thickness larger to make these links more visible]

Kind regards,