Thanks again, Mayayana!
Post by MayayanaAs Helmut said, it can mean digital rights management.
About as many people translate it as digital restriction
management, since that's what it is. "Digital rights
management" is misleading marketing. DRM doesn't grant
rights or manage rights. It restricts access. I guess it's a
lot like saying pro-life and pro-choice instead of the more
accurate anti-abortion and pro-abortion. People on both
sides of that issue will argue all day about why it's incorrect
and biased to call them what they are. The propagandist
euphemisms make both sides sound more moral and noble. :)
Post by GSMy ebooks are html
packaged in a lockable EXE. I'm looking into also doing same with PDFs.
A lockable EXE? You mean like password protected?
Yes, if the ebook is for sale. Readers require an unlock key, which can
be a password or a software-type serial key. The ebook is lockable to
the machine it's installed on OR a USB device it's installed on. The
machine/device ID is captured at first startup. The reader then clicks
a link in the viewer to where they 'register' the ebook. Here, the
machine/device ID is collected and emailed to me along with the
registration info. I use the machine/device ID to generate an unlock
key that will work only for that machine/device. IOW, it's pretty much
same as licensing software.
Post by MayayanaThe LIT
file I downloaded is just a compressed file. The restriction part is
the encryption.
You're doing that with software help manuals? I'm curious: Why do
they need to be locked?
In this usage they aren't locked. I also manipulate them so as to mimic
the in-process behavior of a CHM.
Post by MayayanaAnd why doesn't a CHM work?
CHMS work fine, and I do use them for some projects. CHMs, however,
don't support scripting and so I use the ebook.exe format if the
content warrants scripting.
Post by MayayanaAnd...if
it's a restricted eBook, how do people read it? Do you ship your own
custom reader with your software? Then people get a password to
unlock the help...something like that?
It can include its own built-in viewer, or use Windows' IE engine.
Readers are emailed an unlock key to activate the ebook. This only
applies to ebooks for sale, and so only after I receive confirmation of
payment do I release the activation key.
Post by MayayanaPDFs are an entirely different approach. The format is open
and available, but it's extremely complex. I once delved into
writing a PDF parser and gave up. It was just too much work.
PDFs themselves are not lockable. The restriction is just a flag
saved in the file. It only functions if the program that opens
the PDF checks the flag and acts accordingly. Most PDF software
does follow the flag's directive, but it doesn't have to. It's actually
an arbitrary crippling that could just as easily be done with any
file format. I suppose the only reason that PDF readers build in
"cripple-respect" is because Adobe started that tradition
by positioning PDF as an opaque digital object to transfer corproate
letterheads and magazine excerpts from the source to a remote
printer. In other words, PDFs (and to some extent DOCs) provided
the illusion of paper-like palpability to a business world accustomed
to being awash in official documents printed on paper. Yet the
PDF file itself actually has no restrictions. It's immutability based on
mutually agreed illusion. :)
Yes, I already work with PDFs in this context and so I'm familiar with
all its nuances. (I also do PDF ebooks for clients) What I'm hoping to
achieve is the same ability to do what I currently do with the
ebook.exe stuff. It's just a matter of including a PDF viewer in its
compile. The new IE viewer has this built-in and the IE engine supports
viewing PDFs in the browser on a new tab OR new 'web page' window. In
this case, all the security of the ebook.exe will apply to PDF-based
ebooks. Also, the product will be able to include both formats when
compiled.
Post by MayayanaI've recompiled XPDF and SumatraPDF myself, to ignore the
restrictions flag. It only requires editing the code to not check the
flag. Both XPDF and Sumatra are OSS. I haven't made my code public
only because I wanted to respect the intentions of the OSS authors.
The problem here, to my mind, is that
a lot of people put restrictions on their PDFs for no good reason.
If I download a PDF and want to read it, I usually want to translate
it to plain text because PDF format is a pain in the neck. It's designed
for printing, not for reading. On the other hand, if I print it I usually
want to print it as plain text, too, so as not to waste ink on pointless
page decoration. In most cases there's no reason for limitations in that
regard.
1) A few years ago I was in a car accident and downloaded the report
form. It was a PDF. I had to fill out 3 copies. But the State of Mass.
had locked the file so that I couldn't edit it! I ended up doing 2
screen shots and filling in the form as a BMP in Paint Shop Pro. Then
I printed the BMPs. I'm guessing that someone in state gov't just
locked the PDF without thinking, with some vague notion that official
documents are too official to leave unlocked.
In this case I would open the PDF in my authoring software, fill in the
form fields, save and return to sender.
Post by Mayayana2) I have a blind friend who uses text-to-speech software. He sometimes
gets PDFs that are actually made up of scanned pages, saved in the
PDF as BMPs. He can use OCR software on the BMPs, but only if
he can take them out of the PDF. If the material in question is free
to the public then there's no reason for the BMPs to be locked in.
I agree with you that restrictions should be reasonable/sensible. In my
case I don't go beyond activation restrictions, whether it be certain
pages, certain chapters, or the entire ebook. Once accessed, readers
can do whatever they want.
Also, I don't use BMPs unless it's for images that I can't convert to
GIF format in Paint Shop Pro. In all cases, I prefer GIF images whether
it's CHM, EXE, or PDF. I insist that all text be just text and not a
scanned image of a doc.
Just to give an example, I had a client who authored some manuals in MS
Word and exported the doc as PDF. The Word files were over 62mb each,
largest one being 123mb. I redid these in MS Excel, reworking the
images in PSP, and putting the text directly into the worksheet. The
total of 4 Word docs was 428mb. All 4 were duplicated inside a single
Excel file and its size was 4.25mb (including index sheet). The PDFs
created from these worksheets are less than 900kb including permissions
and bookmarks, and default display settings. My point is that there's
lots of business to be had making the 'consumer' PDF solution results
into more e-friendly products, and so my interest in having same
capability with PDFs as I do with my ebook EXEs.
Post by MayayanaPost by GSI expect something like DsoFile.DLL is what AlJones is after since the
files he's looking at are compound docs by structure.
Yes, I guess that if that works it will provide an easy way to get the
"meta" file content. If it doesn't work it could be accessed directly.
Unfortunately, it looks like either method requires a dependency. DsoFile
is not a Windows system file. It would have to be added to one's software
install. Though it might be feasible to write VB code to do the same
thing. According to MS, DsoFile is just a wrapper for the IPropertyStorage
interface. There may be VB code for that around somewhere, like
at Eduardo Morcillo's website.
Yes, it's a wrapper for that interface which has to be distributed with
our project. I'd love to find a VB equivalent that we can package in
our projects but haven't found anything that I'd use. I know there are
pure VB solutions out there because I've download a few for reviewing.
I might have even downloaded something from Eduardo's website. I don't
think there's anything on Brad Martinez's website.
An alternative to DsoFile is Dan Appleman's dwProp.dll (not free). It
has one drawback in that it classes the 'Keywords' property as a
DocumentSummaryProperty rather than a file SummaryProperty. I bought
this to obviate the issue that in certain cases DsoFile will not write
the 'Title' prop if there's no other props populated with values. This
is a major concern for my app that uses it since 'Title' is the only
way to tell what the file contains because the filenames are
alpha-numeric and may/may not have a file extension.
The drawback with dwProp is (as explained above) that it won't write
the Title prop to plain text files on NTFS volumes that support the
NTFS FileSummaryProperties. As of Win6 this is no longer supported for
non-compound file structures such as TXTs or the like.
DsoFile does handle the Keywords property correctly, though it should
be noted that (as of Win6) in a compound structure file this property
is named "Tag" on the 'Details' tab of the property dialog.
Post by MayayanaI just looked at a LIT file to see what the compression method is.
7-ZIP calls it a CHM. Interesting. It also says an HXS is a CHM. So I guess
CHM format is a sort of class of file. Other than 7-ZIP I have no
idea what can open a CHM. Looking at it in a hex editor, both CHM and
LIT seem to consist of a large header that lists the files inside and the
compression type. Then at a further offset is the actual compressed data.
I'm guessing it's probably similar to CAB files, which typically use either
MSZIP or LZX compression. So parsing the file from VB would be a big
project. If it were me I'd look into IPropertyStorage, in hopes of getting
a compact, dependency-free and dependable method of accessing any
"metadata" that Microsoft has written.
I'd be interested to see if my conversion app can process a LIT same as
a CHM. Any ideas where I can get a sample? Or could I just do a Search
on my own machine?
--
Garry
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc