Since build 384, some comment tools do not show the line preview for about 2 mm at the beginning of drawing

[rakunavi]

Hello all,

In build 384 or later, when drawing comment using the following comment tools, the preview line at the beginning of the drawing temporarily does not appear on the screen.

• Rectangle
• Oval
• Polyline
• Polygon
• Cloud
• Perimeter
• Area

In other words, this issue does not occur with the Line, Arrow, Pencil, and Distance comment tools. The period of non-display is approximately 2 mm at the actual distance on the screen and does not affect the actual comments themselves that are drawn. I don't know if this is a good analogy, but it is like when a car starts to drive at night and the front lights come on a little later. As shown in the following verification video, the preview line is displayed immediately after drawing for builds up to build 383.

• Animation.gif

There is no mention of this behavior in the version history, and I don't see any advantage in delaying the preview. To me, the behavior up to build 383 seems more normal.

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.2.1 build 385
- OS Version: Windows 11 Home 23H2 Build 22631.3296
- PC Model: Lenovo IdeaPad C340-15IWL, HP All-in-One 22-c0xx

[Daniel - PDF-XChange]

Hello, rakunavi

To my knowledge, this was added due to some popular demand, to prevent accidental placement of comments (and specifically for stamps) to prevent users from accidentally changing the default stamp size to one too small to see). 2mm is a small enough increment that it should not inconvenience anyone but has the advantage of preventing unwanted extra placements which you need to later remove.

As for why this is not mentioned in the build history, it must have been overlooked, I will talk to the build team and see if we can get that added in soon.

Kind regards,

[rakunavi]

Hello Daniel, thank you for your reply.

To my knowledge, this was added due to some popular demand, to prevent accidental placement of comments (and specifically for stamps) to prevent users from accidentally changing the default stamp size to one too small to see).

If that is the reason, it would be sufficient to limit the effect to stamps only. Extending the effect to comment tools in general seems somewhat excessive. Also, if the reason for this change is to prevent unintentional addition of small size comments, why are the line, arrow, pencil, and distance comment tools excluded? I report this issue because I understand the overall behavior of these and am concerned that there may be aspects of this implementation that do not necessarily fully reflect the developer's design intent.

2mm is a small enough increment that it should not inconvenience anyone but has the advantage of preventing unwanted extra placements which you need to later remove.

It might be a bit of an exaggeration to say "it should not inconvenience anyone". For me at least, I have felt a bit uncomfortable with this behavior after build 384. I often draw a polyline starting around a word or phrase in the text, pointing to a note I have written on the side of the page. As shown in the following video, there is not much room between lines of text, so it is not unusual for the length from the start point to the next control point to be less than about 2 mm.

Up to build 383, the preview line was visible immediately after the starting point was specified by clicking, so I could control whether I wanted a right-angle bend or a slight slant from the start. After build 384, I had to do the odd maneuver of moving the mouse slightly to display the preview line and then moving it back to near the original starting point.

• Animation.gif

I appreciate the improvement on stamps, but I think the behavior of the other comments should be reviewed a bit more.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you for getting back to me, I have spoken with the Dev team and we have created the following ticket, to go through and verify there is consistency here at least.
At this time I cannot say whether the Dev team will be revising this to only be a feature of stamps, or if they will choose the other option and ensure that all comments have this initial placement "gap" requirement, but those are the likely options in this case.
RT#6854: Comment placement input delay - Consistency check

Kind regards,

[rakunavi]

Hello Daniel, thank you for taking the time to respond.

I greatly appreciate your confirmation of the developer's intentions.
Whatever the decision, I hope it will be a good usability for many users.
Of course, if it should happen to match my preferences, I will be even happier.

Best regards,
rakunavi

[Daniel - PDF-XChange]

[rakunavi]

Hello all,

This is a supplementary report.

The changes made in build 384 described above also affect moving comments, resizing, and moving control points. For reference, here is a verification video comparing the behavior of build 385 and build 383. The document consists of four types of comments (line, oval, rectangle, and pencil) and a stamp, but the oval and rectangle comments can only be moved by dragging them larger. If you want to move or resize it slightly, you need to perform a unique operation, such as moving it larger and then moving it back. As mentioned at the beginning of the topic, line and pencil comments and a stamp are not affected by this issue, so they can be moved freely in either build 383 or build 385.

• Animation.gif

• sample.zip

To my knowledge, this was added due to some popular demand, to prevent accidental placement of comments (and specifically for stamps) to prevent users from accidentally changing the default stamp size to one too small to see).

This behavior is likely the result of changes made specifically for stamps, but interestingly, the stamps themselves, which are the focus of this update, can be freely moved and resized after creation without snagging, just like line and pencil comments.

I often create small sized comments, so it would be very helpful if the behavior was more natural, with no snagging, as it is up to build 383.

Best regards,
rakunavi

[Stefan - PDF-XChange]

Hello rakunavi,

Thanks for the added detail! I have included that and the gif in the ticket so that it can be taken into account when our devs look at fixing this ticket!

Kind regards,
Stefan