Topics

Protected PDF's

ArtekManuals
 

On 1/27/2016 8:43 AM, Sigurður Ásgeirsson siggi@... [TekScopes] wrote:
Hey HÃ¥kan,

The Chrome PDF viewer is unable to cope with these PDFs, as is iBooks.
By locking the files down this way, you essentially force their unlocking
and re-hosting, because as-is, they're unreadable to a large fraction of
the devices people use.
This probably goes the opposite to what you intended, but there you are.

PS: many thanks for all the docs and help you've provided.

Siggi
Siggi

I am confused by this comment, I just tried opening, downloading, viewing a protected PDF using Chrome without any problems?

Dave

--
Dave
Manuals@...
www.ArtekManuals.com

Craig Sawyers <c.sawyers@...>
 


I am confused by this comment, I just tried opening, downloading, viewing a protected PDF using
Chrome without any problems?

Dave
Me too Dave. Chrome simply opens the file straightforwardly, for saving/printing as needed. Not
being able to cut and paste content is a mild inconvenience, but it is only mild given the unique
content that Hakan has made available.

Craig

 

On Wed, 27 Jan 2016 21:01:52 -0000, you wrote:


I am confused by this comment, I just tried opening, downloading, viewing a protected PDF using
Chrome without any problems?

Dave
Me too Dave. Chrome simply opens the file straightforwardly, for saving/printing as needed. Not
being able to cut and paste content is a mild inconvenience, but it is only mild given the unique
content that Hakan has made available.

Craig
The problem I usually have is that the scans are not suitably scanned
and processed for printing so in order to get good or even legible
results, I have to extract the scans and process them before printing
which requires breaking the protection.

ArtekManuals
 

David

I am not sure what that means .....define "suitably scanned" or
"processed for printing"

Adobe Reader DC allows all kinds of printing options to deal with large
pages (Poster and TILE)

Would you like the schematic parsed so it can being printed 8.5 x 11?

Dave
ArtekManuals


On 1/27/2016 4:15 PM, David @DWH [TekScopes] wrote:

On Wed, 27 Jan 2016 21:01:52 -0000, you wrote:


I am confused by this comment, I just tried opening, downloading,
viewing a protected PDF using
Chrome without any problems?

Dave
Me too Dave. Chrome simply opens the file straightforwardly, for
saving/printing as needed. Not
being able to cut and paste content is a mild inconvenience, but it
is only mild given the unique
content that Hakan has made available.

Craig
The problem I usually have is that the scans are not suitably scanned
and processed for printing so in order to get good or even legible
results, I have to extract the scans and process them before printing
which requires breaking the protection.


--
Dave
Manuals@...
www.ArtekManuals.com

Siggi
 

On Wed, 27 Jan 2016 at 15:38 Artek Manuals manuals@...
[TekScopes] <TekScopes@...> wrote:

On 1/27/2016 8:43 AM, Sigurður Ásgeirsson siggi@... [TekScopes]
wrote:

Hey HÃ¥kan,

The Chrome PDF viewer is unable to cope with these PDFs, as is iBooks.
By locking the files down this way, you essentially force their unlocking
and re-hosting, because as-is, they're unreadable to a large fraction of
the devices people use.
This probably goes the opposite to what you intended, but there you are.

PS: many thanks for all the docs and help you've provided.

Siggi
Siggi

I am confused by this comment, I just tried opening, downloading,
viewing a protected PDF using Chrome without any problems?

Hey Dave,
I tried this on my iPad, and assumed Chrome uses the same PDF viewer across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more accurate
statement is that the iOS PDF viewer is unable to cope?

Siggi


[Non-text portions of this message have been removed]

ArtekManuals
 

Siggi

So you are basically having an an IPAD problem .... I suspect you will
not have problems with a "real" computer...I will keep my further
opinions to myself about Ipads and for that matter Apple OS's in a
technical environment :-) .Flame suit on

Try looking ata small protected file say one about 1MB vs a large 20+mb
file and see if that makes a difference



Dave




On 1/27/2016 6:21 PM, Sigurður Ásgeirsson siggi@... [TekScopes] wrote:

On Wed, 27 Jan 2016 at 15:38 Artek Manuals manuals@...
[TekScopes] <TekScopes@...> wrote:

On 1/27/2016 8:43 AM, Sigurður Ásgeirsson siggi@... [TekScopes]
wrote:

Hey HÃ¥kan,

The Chrome PDF viewer is unable to cope with these PDFs, as is iBooks.
By locking the files down this way, you essentially force their
unlocking
and re-hosting, because as-is, they're unreadable to a large
fraction of
the devices people use.
This probably goes the opposite to what you intended, but there
you are.

PS: many thanks for all the docs and help you've provided.

Siggi
Siggi

I am confused by this comment, I just tried opening, downloading,
viewing a protected PDF using Chrome without any problems?

Hey Dave,
I tried this on my iPad, and assumed Chrome uses the same PDF viewer
across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more accurate
statement is that the iOS PDF viewer is unable to cope?

Siggi

[Non-text portions of this message have been removed]


--
Dave
Manuals@...
www.ArtekManuals.com

 

On Wed, 27 Jan 2016 16:57:51 -0500, you wrote:

David

I am not sure what that means .....define "suitably scanned" or
"processed for printing"
Suitably scanned means with sufficient resolution and bit depth.
Optimum for printing and viewing seems to be 4 bits of grayscale for a
black and white source if post processing to remove the background
white problem is used and somewhere between 300 and 600 dots per inch.
4 bits is poorly supported so 8 bits is much easier to deal with
despite increased storage and processing requirements.

Processing includes proper contrast and background while level. The
later is a massive problem with grayscale scans which should otherwise
produce good results. The background may look white on a monitor but
printer drivers often interpret anything except pure white as gray and
act accordingly. A big improvement can be made by selecting
everything close to white and setting it to pure white which also
helps enormously with compression.

Adobe Reader DC allows all kinds of printing options to deal with large
pages (Poster and TILE)
I have not used Adobe Reader for years and one of the primary reasons
was because of its printing limitations. Foxit Reader was better but
starting with version 5 they removed most of the printing options (and
broke Windows) so I continue to use an old version.

I usually find the easiest way to deal with multiple page sizes is to
extract the pages I am interested in, process them as necessary to
adjust contrast and background white level, and then reassemble them
into separate 8.5x11 and 11x17 doubled sided sections. If I am
working on a specific piece of test equipment, I may cut out specific
figures and recombine them on facing pages to make something like a
crib sheet so I am not flipping back and forth constantly.

Would you like the schematic parsed so it can being printed 8.5 x 11?
If size and rotation is a problem then it usually works in the
opposite way and I end up altering the scans to print on 11 x 17.

While it is difficult to do, I always merge schematics which have been
split up into multiple sections.

Tom Gardner
 

On 27/01/16 23:21, Sigurður Ásgeirsson siggi@... [TekScopes] wrote:

I tried this on my iPad, and assumed Chrome uses the same PDF viewer across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more accurate
statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK

 

On Thu, 28 Jan 2016 01:04:24 +0000, you wrote:

On 27/01/16 23:21, Sigurður Ásgeirsson siggi@... [TekScopes] wrote:

I tried this on my iPad, and assumed Chrome uses the same PDF viewer across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more accurate
statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK
When I tested this, it surprised me by failing when using Adobe
Acrobat 8.0 on Windows but my much older version of Foxit worked just
reporting the PDF as secured as usual.

ArtekManuals
 

On 1/27/2016 8:04 PM, Tom Gardner tggzzz@... [TekScopes] wrote:

On 27/01/16 23:21, Sigurður Ásgeirsson siggi@... [TekScopes] wrote:

I tried this on my iPad, and assumed Chrome uses the same PDF viewer
across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more accurate
statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK

Tom

And your point is?

Dave
ArtekManuals.com
.

--
Dave
Manuals@...
www.ArtekManuals.com

ArtekManuals
 

On 1/27/2016 8:10 PM, David @DWH [TekScopes] wrote:

On Thu, 28 Jan 2016 01:04:24 +0000, you wrote:

On 27/01/16 23:21, Sigurður Ásgeirsson siggi@... [TekScopes] wrote:

I tried this on my iPad, and assumed Chrome uses the same PDF
viewer across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more
accurate
statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK
When I tested this, it surprised me by failing when using Adobe
Acrobat 8.0 on Windows but my much older version of Foxit worked just
reporting the PDF as secured as usual.
Works just fine Under WIN-7 with Adobe Acrobat Pro 9.5 and Adobe Reader DC
Dave



--
Dave
Manuals@...
www.ArtekManuals.com

Vince Vielhaber
 

On Wed, January 27, 2016 8:04 pm, Tom Gardner tggzzz@... [TekScopes]
wrote:
On 27/01/16 23:21, Sigurður �sgeirsson siggi@... [TekScopes] wrote:

I tried this on my iPad, and assumed Chrome uses the same PDF viewer
across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more accurate
statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK
Linux, Firefox, Adobe plug-in: opens and looks just fine.


--
Michigan VHF Corp. http://www.nobucks.net/ http://www.CDupe.com/
http://www.foggymist.com The Foggy Mist Emporium

Tothwolf
 

On Thu, 28 Jan 2016, Tom Gardner tggzzz@... [TekScopes] wrote:
On 27/01/16 23:21, Sigurður Ásgeirsson siggi@... [TekScopes] wrote:

I tried this on my iPad, and assumed Chrome uses the same PDF viewer across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more accurate
statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK
$ okular SUP3010.pdf
"Please enter the password to read the document:"

$ xpdf SUP3010.pdf
Error: Weird encryption info
Error: Incorrect password

$ pdfinfo SUP3010.pdf
Error: Weird encryption info
Error: Incorrect password

$ file SUP3010.pdf
SUP3010.pdf: PDF document, version 1.7

$ pdfinfo SUP3010.unlocked.pdf
Creator: PDFUnlock! (http://www.pdfunlock.com)
Producer: iText® 5.5.8 ©2000-2015 iText Group NV (ONLINE PDF SERVICES; licensed version)
CreationDate: Wed Jan 27 06:22:36 2016
ModDate: Wed Jan 27 06:22:36 2016
Tagged: no
Pages: 12
Encrypted: no
Page size: 612 x 792 pts (letter)
File size: 713629 bytes
Optimized: no
PDF version: 1.4

$ file SUP3010.unlocked.pdf
SUP3010.unlocked.pdf: PDF document, version 1.4

Tothwolf
 

On Wed, 27 Jan 2016, Artek Manuals manuals@... [TekScopes] wrote:
On 1/27/2016 8:04 PM, Tom Gardner tggzzz@... [TekScopes] wrote:
On 27/01/16 23:21, Sigurður ?sgeirsson siggi@... [TekScopes] wrote:

I tried this on my iPad, and assumed Chrome uses the same PDF viewer
across platforms. It looks like on iOS it uses the OS-provided PDF
viewer, as iBooks, Safari and Chrome all fail to render the doc I
tested (< http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf>
IIRC).

Chrome on Linux has no problem with it, though, so maybe a more
accurate statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK
And your point is?

Dave
ArtekManuals.com
Don't assume everyone uses Windows and Adobe Acrobat Reader 9+.

[Non-text portions of this message have been removed]

Tothwolf
 

On Thu, 28 Jan 2016, Tothwolf tothwolf@... [TekScopes] wrote:
On Thu, 28 Jan 2016, Tom Gardner tggzzz@... [TekScopes] wrote:
On 27/01/16 23:21, Sigurur sgeirsson siggi@... [TekScopes] wrote:

I tried this on my iPad, and assumed Chrome uses the same PDF viewer
across platforms. It looks like on iOS it uses the OS-provided PDF
viewer, as iBooks, Safari and Chrome all fail to render the doc I
tested (< http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf>
IIRC).

Chrome on Linux has no problem with it, though, so maybe a more
accurate statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK
$ pdfinfo SUP3010.pdf
Error: Weird encryption info
Error: Incorrect password

$ file SUP3010.pdf
SUP3010.pdf: PDF document, version 1.7
Just a further note... I can open all of the version 1.4 and 1.6 pdf
documents without any issues, but all of the version 1.7 documents fail in
the manner shown above.

My guess is that Adobe Acrobat 9 and above default to producing backwards
incompatible v1.7 documents with the new "encryption" format which isn't
well supported by most third party and open source pdf rendering engines.
As the pdf format itself is an open standard, I can only think of one
reason Adobe would have done this...

It is of course incredibly easy to remove the protection flags and convert
v1.7 documents to earlier pdf versions (even fully password protected pdf
documents can be decrypted in seconds using something like Amazon EC2 or
even a few days on a modern PC), so as much as I understand the desire to
keep people from trying to sell collections of these sort of documents on
eBay, this certainly isn't going to deter them all that much.

I think the best way to deter such attempts at profiteering would be to
make sure these documents are well indexed with various search engines
(such as what archive.org has done with OCR'd text searchable versions
kept together with the original pdf file in their online collections) so
that people who search for them will find the originals /before/ any
potential eBay listings.

Hakan -- It was not my intention for you to take my earlier comments as
criticism of your efforts. I was simply stating that I was unable to open
these documents using the various pdf rendering and viewing tools I had
available to me on my computer. If I'm criticizing anyone, it would be
Adobe for forcing pdf version 1.7 as the default for Acrobat 9 and
breaking backwards compatibility with the majority of the third party and
open source pdf rendering/viewing software.

[Non-text portions of this message have been removed]

Tom Gardner
 

On 28/01/16 01:21, Artek Manuals manuals@... [TekScopes] wrote:

On 1/27/2016 8:04 PM, Tom Gardner tggzzz@... [TekScopes] wrote:

On 27/01/16 23:21, Sigurður Ásgeirsson siggi@... [TekScopes] wrote:

I tried this on my iPad, and assumed Chrome uses the same PDF viewer
across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more accurate
statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK

Tom

And your point is?
Points of information, no more, no less.
Explicitly no conclusions nor recommendations nor wishes.

Cross-platform compatibility is difficult for small organisations to assess,
because they don't have range of platforms on which to try things.


[Non-text portions of this message have been removed]

Marian B
 

On 28.01.2016 02:38, vev@... [TekScopes] wrote:
On Wed, January 27, 2016 8:04 pm, Tom Gardner tggzzz@... [TekScopes]
wrote:
On 27/01/16 23:21, Sigurður �sgeirsson siggi@... [TekScopes] wrote:

I tried this on my iPad, and assumed Chrome uses the same PDF viewer
across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more accurate
statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK
Linux, Firefox, Adobe plug-in: opens and looks just fine.
Linux, Firefox, Okular works for me just fine, too.

Settings -> Configue -> Obay DRM limitations is not checked.

Cheers, Marian

Albert Otten
 

Linux, Firefox (view in Firefox): fine
Linux, Firefox, view with evince: fine
Ĺinux, saved file, evince: fine
Looks here we are reporting our own specific problems.

PDF 1.7 is a standard since 2008(!). Also readable by Adobe Reader 8. [Info Wikipedia.] But Hakan's files are PDF 1.7 Extension level 3. Those extensions are Adobe inventions and not a standard; Adobe 9 or higher is needed (also 2008). Level 3 introduces 256-bit AES encryption. For Chrome, DocHub (free in the webstore) can handle this it seems (I don't have Chrome myself, info from chrome.google.com).

Albert

Tom Gardner
 

On 28/01/16 11:33, public@... [TekScopes] wrote:
On 28.01.2016 02:38, vev@... [TekScopes] wrote:
On Wed, January 27, 2016 8:04 pm, Tom Gardner tggzzz@... [TekScopes]
wrote:
On 27/01/16 23:21, Sigurður �sgeirsson siggi@... [TekScopes] wrote:
I tried this on my iPad, and assumed Chrome uses the same PDF viewer
across
platforms. It looks like on iOS it uses the OS-provided PDF viewer, as
iBooks, Safari and Chrome all fail to render the doc I tested (<
http://hakanh.com/dl/docs/kitinstructions/045-0034-00.pdf> IIRC).

Chrome on Linux has no problem with it, though, so maybe a more accurate
statement is that the iOS PDF viewer is unable to cope?
Linux, Firefox, Okular: fail
Linux, Firefox, Evince: fail
Linux, Firefox, gv: opens but almost illegible
Linux, Firefox, epdfview: fail
Linux, Chrome: OK
Linux, Firefox, Adobe plug-in: opens and looks just fine.
Linux, Firefox, Okular works for me just fine, too.

Settings -> Configue -> Obay DRM limitations is not checked.
That looked promising, but it doesn't work for me, sigh.
I get dumped into the KDE wallet (which I've never used)
and after exiting that okular can't open the file.

Vendor lock-in is a real pain and drain on people's time.

Tom Gardner
 

On 28/01/16 11:57, aodiversen@... [TekScopes] wrote:

Linux, Firefox (view in Firefox): fine
Linux, Firefox, view with evince: fine
Ĺinux, saved file, evince: fine
Looks here we are reporting our own specific problems.
Just so; exactly. If I was the only one having problems, your comment would be a sufficient response.

But it seems quite a few people are having problems for the reasons you define below...

PDF 1.7 is a standard since 2008(!). Also readable by Adobe Reader 8. [Info Wikipedia.] But Hakan's files are PDF 1.7 Extension level 3. Those extensions are Adobe inventions and not a standard; Adobe 9 or higher is needed (also 2008). Level 3 introduces 256-bit AES encryption. For Chrome, DocHub (free in the webstore) can handle this it seems (I don't have Chrome myself, info from chrome.google.com).
So Hakan has, probably unwittingly, chosen vendor-specific non-standard encodings.

With this knowledge, Hakan can choose what they think is the most appropriate course of action.