How to show only results that don't include hyphen-minus when searching for keywords that don't include hyphen-minus?

[rakunavi]

Hello all,

When using the find or search commands in the PDF-XChange Editor, results that include hyphen-minus (*) are also shown.
(*) Hyphen-minus "-" : U+002D https://en.wikipedia.org/wiki/Hyphen-minus

For example, when searching for "320001", not only "320001" but also "32000-1" will be shown. Please tell me how to show only the results that include "320001" when searching for "320001" as in other applications.

• figure.png

Thank you for taking the time to read this message.

Best regards,
rakunavi

- PDF-XChange Editor PRO Version: 10.5.2 build 395
- OS Version: Windows 11 Pro / Home 24H2 Build 26100.3775
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL

[Daniel - PDF-XChange]

Hello, rakunavi

From what I can find, there is apparently no way to control this at the moment. I have raised this with the Dev team for consideration, and possibly implementation in the future. For now I am sorry to say that I do not have a workaround to offer.

[Edit]
Immediately after posting, I had a crazy idea which actually worked. This is clearly not ideal, but it seems to work:

image.png

Advanced search functionality is interesting, to say the least.

I will keep the request to the Dev team out there however, as there may be cases where you need to search for a collection of terms, and making an exclusion list like this would clearly not be ideal.

Kind regards,

[rakunavi]

Hello Daniel, thank you for taking the time to look into this.

You have a similar thought process to mine. I also thought for a moment to write that "crazy idea" you wrote about.

For example, something like this, using "320001" as the search term to exclude "3-20001 32-0001 320-001 3200-01 32000-1".

• figure1.png
  
  
  figure2.png

• sample.pdf

However, I immediately noticed something a little odd. For example, if you search for "320001" and exclude "32000-1", the result is as follows.

• figure3.png

At first glance, it looks good because only "320001" is displayed, but you will notice something strange right away. Yes, too many results are excluded.

So, as a test, here are the results of a search using "320001" as the search term and excluding "32001".

• figure4.png

The following is the result of a search using "320001" as the search term and excluding "3201".

• figure5.png

In addition, the following is the results of a search using "320001" as the search term and excluding "321".

• figure6.png

Neither "32001", "3201", nor "321" will return any results when searched alone.

• figure7.png
  
  
  figure8.png
  
  
  figure9.png

Many would expect the same relationship to hold with the mathematical formula that subtracting zero from a number does not change the original number, but this does not seem to be the case.

I felt that there was a great darkness that I should not go into, so I pretended that I did not see everything and quietly closed it. Then I wrote the first question with the faint hope that I just did not know how to operate it correctly.

I am happy and sad to say that everything turned out to be close to what I expected, but even with this sample file, Acrobat gives me the expected results without having to worry about anything. And for more than 15 years, or even longer....

Please give my best regards to the developer.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

That... seems "a little" problematic indeed. I have raised this secondary item with the Dev team, as a separate report from your previous post.

Once I hear back from them, I will let you know whats happening (Or post the ticket number if we make a ticket for it)

Kind regards,

[rakunavi]

Hello Daniel, thank you for your reply.

We, the users, will quietly watch to see how adequately you can assess the importance of the issue, and then judge the value of the software.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, Rakunavi

Ticket made for this issue:
RT#7468: Advanced Search "none of" terms sometimes break results
[Edit - Clarification of scope]
RT#7468: Search/find hyphenation confusion.

(I see also you have posted a few new items since I ran off to discuss the previous issue, I will followup on those as soon as I can)

[rakunavi]

Hello all,

I have found that setting "all of these words" equal to "any of these words" or "this exact phrase" equal to "any of these words" when specifying the search terms produces search results that accurately reflect the presence or absence of hyphen-minus in the search term.

• figure1.png
  
  
  figure2.png
  
  
  figure3.png

• sample.pdf

Best regards,
rakunavi

[rakunavi]

Hello all, I would also like to add some additional information.

A similar strange behavior can also be seen in the "Links from Bookmarks" feature.

To ensure accuracy of verification, I have created a new sample file that covers all possible combinations that can occur with or without a hyphen-minus in the gap between the 6-digit numbers. There are 32 possible combinations, calculated to the 5th power of 2. Also, the difference is that this time they are all base content to work with "Links from Bookmarks" feature, whereas last time they were all comments.

• newsample.pdf

In the first half of the video, searches were performed using "320001," "32000-1," and "3-20001" as a search term respectively. In the second half of the video, "320001", "32000-1", and "3-20001" are created as a bookmark and links are generated using the "Links from Bookmarks" feature.

• Animation.gif

As you can see, the "Links from Bookmarks" feature has the same problem of unintentionally including hyphen-minus characters in the link target as I pointed out in the previous post on the Search feature. Perhaps the internal algorithm used by the "Links from Bookmarks" feature is the same or similar to that used by the Search feature.

Since the Search feature and the "Links from Bookmarks" feature are different features, it is not surprising that the number of hits and the number of links are different. By no means am I saying that it is normal. I mean that even when behavior is abnormal, the abnormality is within predictable limits.

However, what is most noteworthy here is that the number of links created for the bookmark "32000-1" in Case B2 is 8, while the number of links created for the bookmark "3-20001" in Case B3 is 16.

• figure.png

As mentioned in the introduction, the sample I have created covers all mathematical possibilities. Therefore, the same 16 hits for the search terms "32000-1" in case A2 and "3-20001" in case A3 is quite reasonable in that the numbers in the two cases match, although the numbers themselves are strange, as I mentioned in my previous post. However, why is there a difference in the number of links between Case B2 and Case B3 when using the "Links from Bookmarks" feature?

It is incomprehensible that the number of links differs between "32000-1" and "3-20001" when the only difference is the position of the hyphen-minus. Only when the results are predictable can one use the tool with confidence. In this sense, the behavior of the "Links from Bookmarks" feature is more unusual than that of the Search feature first reported.

For the Search feature, the method just reported may barely be a workaround, but the trouble is that no similar workaround has been found so far for the "Links from Bookmarks" feature.

Thank you for taking the time to read this message.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you again for the continued investigation. I am unsure why the combined use of two fields functions as a workaround in this way, and so that has been raised with the team for review.

Following that, the bookmarks issue does seem strange. Practically speaking, I expect both of these are fragments of some level of hyphenation "allowance" so that both functions work with documents that have varying levels of "word wrapping" in place, what with PDF being somewhat "wrapping agnostic" the workarounds to allow that are quite... "Sensitive" (is the best word I can think of?), and may be the root cause of both issues. That said, in both cases, we see a number of results with hyphens in place that do not get caught, so even if that is the reason, there is still something not quite right about it.

I am sure the Dev team will be able to get to the bottom of it, but I do expect this to be a large and rather complex undertaking.

Kind regards,

[rakunavi]

Hello Daniel, thank you for taking the time out of your busy schedule before the release of the new build.

Thank you for creating the ticket. It is very important to distinguish between "1-1-1" and "111" as the 1-1-1 format is often used in page numbering. I hope that the root cause of the problem can be identified and improved without affecting the word hyphenation process in any way. This problem seems to have existed since the days of PDF-XChange Viewer, and I am glad to find it by chance.

Ticket made for this issue:
RT#7468: Advanced Search "none of" terms sometimes break results

The title of the ticket gives the impression that the problem is limited to Advanced Search, but as I said at the beginning of the topic, the problem occurs in both the find and search functions. I am sure you are aware of this, but I would like to comment just in case.

When using the find or search commands in the PDF-XChange Editor, results that include hyphen-minus (*) are also shown.
(*) Hyphen-minus "-" : U+002D https://en.wikipedia.org/wiki/Hyphen-minus

Please give my best regards to the developer.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

That is a good point, I have modified the name of the ticket to extra clarity in that respect (and edited my previous post), sorry for the worry.
RT#7468: Search/find hyphenation confusion.

[edit]
Secondary ticket made, this one is an FR, to control the inclusion of hyphens at all in search results:
RT#7504: FR: avoid hyphenation in search

Kind regards,