I don't quite get how to reproduce this. When you say 'Save "data:text/plain,google.com www.google.com" as a pdf and open in chrome', does that mean pasting the text "data:text/plain,google.com www.google.com" in a file, rename it to PDF? Or do you mean paste that in an html file, open it in Chrome, print to a PDF?

Paste the "data:..." url in the location bar of Chrome and hit enter. This
will show an html page with the content from the data-url. Save this page
as a pdf file using a pdf printer. Open the resulting pdf in Chrome.

Sorry for not being completely clear about this. I saw the technique used
in another ticket and thought it was a good way of generating test files.

Den 20. nov. 2017 6.05 PM skrev "hnakash… via monorail" <
monorail+v2.1948542879@chromium.org>:

Thank you for providing more feedback. Adding requester "hnakashima@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thank you for clarifying. I reproduced the behavior described.

The reason google.com does not show as a link and www.google.com does is that neither are links (hence why other PDF viewers don't create a link there), but PDFium does a best-effort step to add links for strings that are obviously urls. That means www.anything.com and https://anything.com turn into links, but anything.com does not, because the heuristic is conservative.

Marking as WAI, but thank you for the report.

Thanks for the quick reply. If I may ask, is there a (technical) reason for this behaviour? Even while being conservative, I don't see any reason not to show text like google.com as links (monorail, for instance, easily recognises the link) and as a user it feels weird that some obvious links are showed as links while other obvious links are not.

Hmm ... apparently I may not. I guess this is just not a priority :-(

It maybe possible to make the heuristic less conservative but it quickly becomes a hard problem as you can't just match on the suffix with so many TLDs available now.

If you wanted to try we're happy to accept patches but this isn't something we're looking into at the moment.

Sorry, I missed your comment. We could do matching for some common suffixes like .com and .org, I think that would be reasonable.

Relevant code is at core/fpdftext/cpdf_linkextract.cpp

I'll actually leave this open and work on it when I have cycles.

Thanks, that sounds really great. Adding support for common domains would be a great improvement.

I found the relevant monorail link recognition here for inspiration: https://chromium.googlesource.com/infra/infra/+/master/appengine/monorail/features/autolink.py