View Single Post
  #98  
Old September 20th 20, 11:58 AM posted to alt.comp.os.windows-10
Carlos E.R.[_3_]
external usenet poster
 
Posts: 1,356
Default Word look alike?

On 19/09/2020 20.00, VanguardLH wrote:
"Carlos E.R." wrote:

On 19/09/2020 03.34, VanguardLH wrote:
"Carlos E.R." wrote:

In this case, on her old laptop Word would not do the conversion to
PDF, and being confined I could not have a look. So she mailed me the
.docx, and I did the conversion to PDF using LO in Linux. Nobody
noticed.

No need to have Word, or any other app, incorporate PDF conversion to
output a PDF file. Use any PDF printer emulator you want. ANY app that
has a Print function can output to a .pdf file.


I know that, but as we were all confined to our homes I could not go
there not she here, for me to add whatever was necessary or to explain
the procedure.


She cannot install software herself?


You know that there are people that are the full reverse of a computer
geek. You try to explain something and they go in denial mode, "I don't
understand anything", with even the most simple of computer tasks.


There is very little to do when installing a virtual printer. Just run
the .exe file, and it's installed. Some have lots of configuration
options, but she could just start with the defaults and learn later how
to tweak the virtual printer's configuration. However, probably the
first setting that I would change is the default save location.


I know. But impossible.


I currently use Bullzip PDF Printer, but I've used PDFCreator in the
past. There are lots of PDF printer emulators aka virtual printer
software. Some are listed at:

https://en.wikipedia.org/wiki/List_o...are#Creators_3
https://en.wikipedia.org/wiki/List_o...inter_software


Good to know.

The new laptop came with a print to PDF printer already defined.

I did not try to see what happens to an URL in such a conversion: is it
clickable in the PDF?


Putting clickable strings (e.g., URLs) into PDFs requires a PDF editor,
not a PDF viewer and not a PDF converter. They "print" what they see.


That's what I thought.

They do not interpret whatever code or scripting is employed within the
document. Every PDF viewer that I've used lets me copy a string from
the PDF document, so she can copy the URL string and paste it into the
address bar of a web browser.


Well, I know for certain that the LO integrated converter to PDF does
interpret links and creates a table of contents.

Then the print to PDF function would not work for her, because the
recipients of the PDFs expect links to work directly.


Virtual printers do not support every feature of a PDF, nor do PDF
converters, like those integrated into office suites. They are not
clones of Adobe Acrobat. For example, it is possible with a PDF editor
to embed directives in a PDF document that will automatically run a
command, launch a URL when the document is opened, or open another PDF
file. This are considered highly dangerous. A malicious PDF that ran a
command on just loading the PDF (in a viewer that supported the option
or had it enabled) means it could, say, format your drive, reconfigure
and disable your network connections, ransom your files, and so on. A
PDF that automatically launched a URL could take you to a malicious
site. A PDF that launched another PDF where that other PDF launched
another PDF, and so on, could end up opening hundreds of PDF files
making use of your computer impossible during all those loads (and
perhaps just 2 of them could keep opening each others to get stuck in a
loop). Regardless of the defaults for a PDF viewer, if it supports
auto-run of commands, auto-launch of URLs, or auto-launch of PDFs just
on loading a PDF then you should disable those, um, features. They are
hazardous. Virtual printers don't have all the features of Adobe
Acrobat, and I've not run across a virtual printer that will embed
auto-run, auto-load, or auto-open commands into the output PDF,
especially since those are something the PDF author must code into their
PDF document.


Yes, I know.


The URL in your document (to which you would "print" to a PDF file) is
just a text string. It is not some active object to get replicated in
the output file. It's just a string. So, that's how it appears in the
"printed" output, too. If you want to "print" an intact HTML web page
then you need to instead Save the HTML page, so the HTML tags will be in
place and intrepeted as such to make URL strings into A tags that are
clickable in the HTML page you saved. Virtual printers behave like
printers. When did you ever print to paper with the ability to click on
a URL string on that paper?

The virtual printer "prints" what it sees. It does not interpret the
HTML code, or whatever code or script a document might be written in, to
parse out URL strings to make them clickable inside the PDF file. If
the document shows the URL string then the URL string will be available
in the output PDF file, and where you could copy the string to paste
into the address bar of a web client. If, instead, the HTML document
shows the comment field of an A tag, as in:

A href="http://host.domain.tld/path&args" ... comment /A

and the comment field has nothing of the URL string but is some
description, like "This is my site", then the virtual printer only sees
the comment which may not be a URL string (for you to copy and paste
elsewhere).


It is not that complicated with LO. When I enter and URL that seems an
URL, say

http://somthing.org

LO automatically shows it in blue and says it is a link; and when it
converts the page to PDF it keeps it as a link. I assume Word does the
samething


PDF virtual printers are not PDF editors. They are a quick method to
get the visible document outputted into a .pdf file. As an example, in
a web browser, I do a Google search on something. A whole bunch of
results are listed. All of them have a description (i.e., they show a
comment) as their clickable link. They do NOT show the URL to the
target site. There are lots of HTML clickable elements in the original
HTML page, but they are merely shown as text in the PDF output file.
They were shown as text (or image) in the original documents, so that's
how they are presented in the conversion to a PDF file. There is no
HTML code to PDF code translation. That's far beyond the intent of
virtual printers. They are to print, not generate a scripted document.

If she is going to insert a URL string into a Word document (not by
copying just a string, but by using Insert - Hyperlink to facilitate
employing Word-specific code to delineate a clickable URL string), why
wouldn't she supply the Word document instead of *printing* it to a PDF
file where just the URL *string* would get displayed?


Because some of the recipients (parents or kids) will use a tablet, for
instance. And because it is not wanted that the recipients can edit the
documents.

If the original
document where an .html file using A href={url]comment/a where just
the comment field would get displayed, she could make the comment field
have the same string as the href's value (URL string) if it was her HTML
file to edit. If it is someone else's HTML file (that she doesn't want
to save and edit), she could send the URL to the location of that web
document; i.e., point someone to where is the web page. She could Save
the web page, and send that as an attachment in an e-mail (*).

(*) Be careful when saving a web page viewed within a web browser.
Saving as "Complete" means saving the main page but creating a
folder with seperate files for all the resources within the page,
like images, CSS files, and other resources the main page
references. You end up with main.html page and a folder of
ancilliary files, so you have to zip up the file and folder and
send that to ensure the recipient gets all the files comprising
the web page. You could Save as HTML-only, but that just outputs
the main page and does not include all the resources it
references. The recipient of the main page only won't see images
or other resources, so the web document may be incomplete or not
even usable.

There is the .mhtml format which is Microsoft's archive HTML save
format. It does as above where the main.html page is outputted along
with a folder containing the ancilliary files, but rolls them into an
archive file, much like the zipping that I mention above. Only IE and
Edge natively support output to and reading from .mhtml archive files.
Well, it's a Microsoft proprietary format. There may be extensions to
add MHTML support, but I've not bothered with those for a long time. As
I recall, there was an experimental flag in Chrome that added a Save
option to MHTML; however, experimental features come and go, and, I
think, the MHTML experiment got killed.

The Save Page WE extension (Firefox and Chrome) does the same thing as
saving a web page into a unified output file.

https://addons.mozilla.org/en-US/fir.../save-page-we/
https://chrome.google.com/webstore/d...jamoafof?hl=en

That creates a single .html output file. I've not used it.

If the web page is simple (usually meaning you wrote it, but then why
did you use HTML?) then Save as Text is often sufficient. No clickable
URL strings, but they can be copied and pasted. For most web pages you
find on the Web, they contain loads of crap that you don't want to save.
I use the Print Edit WE extension to select just what part(s) of a web
page that I want to save, and all the other crap is excluded in the
output file (whether that be to a real printer or virtual printer saving
into a .pdf file).



--
Cheers, Carlos.
Ads