Re: DRM in xpdf
On Fri, 25.04.2008 at 22:16:48 +, Miod Vallat m...@online.fr wrote: For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). Go ahead, ignore the authors wishes. Show your disrespect. Your logic implies GPL respects authors. It does, actually (if you want to flame me, please take it off-list), but I'm pretty sure that Martin was talking about the DRM shit that you (we) should respect, in his opinion. -- Kind regards, --Toni++
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
Hi, On Sun, 27.04.2008 at 11:10:49 -0700, Matthew Dempsky matt...@dempsky.org wrote: His use case for PDF's DRM was simply to protect students from accidentally printing the animated slides instead of the still 4-up slides. yes, but this is a weak use case. I, for one, would expect students to have no trouble to read simple notices about appropriate usage of their learning material, and make an informed decision thereafter. But maybe I'm just expecting too much when I hear people say that (University) students need a calculator to compute 6 x 4 these days (no kidding!). -- Kind regards, --Toni++
Re: DRM in xpdf
On Wed, Oct 28, 2009 at 09:48:13AM +0100, Toni Mueller wrote: It does, actually (if you want to flame me, please take it off-list), but I'm pretty sure that Martin was talking about the DRM shit that you (we) should respect, in his opinion. Or maybe he just don't want to be the one stripping out that DRM shit. Saludos. -- DISCLAIMER: http://goldmark.org/jeff/stupid-disclaimers/ This message will self-destruct in 3 seconds.
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On 26 Apr 2008, at 9:30 PM, Marc Espie wrote: We're talking about stupid, evil, legal DRM here. The pdf document basically says `oh, you're not supposed to do things with this document, because I say so'. There's nothing that prevents anyone from doing anything with the document. If anything, our xpdf should probably display a notice that says `the author of the document thought you should not be able to print it... or whatever'. Finally, some sense, thanks. The real issue for me at least is the fact that one is prepared to modify (in this case xpdf) away for what ever standard it is written against, modified away from the original software distribution without documenting the change, informing the end user who installs the modified software so they can make an informed decision as to whether they still want to use the modified version or go off and install the unmodified version. In the case of xpdf, everyone just wanted to shout we can modify the software because we can. If the modification is some where documented, then I and others don't sit scratching our heads as to why this no longer works the way it should according to the standard or whatever. But there is no actual protection in the document. It's all stupid shackles in software. This is a case where I strongly believe in freedom: the end user should be able to decide what they can do with the document. And equality: knowledgeable technical users shouldn't have an edge. It's completely hypocritical to say `oh, you can recompile the software to remove the restriction', because it shuts down some users. As far as I'm concerned, you've got two levels of protection: legal and technical. This `drm' part of pdf is purely legal: you get a document, you are informed you're not supposed to do such and such, and THAT'S IT. There's no technical protection to speak of. For me, the legal barrier is quite enough. As adult, you can make an ethical choice whether or not to obey the spirit of the document author. Ian McWilliam
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On 26 Apr 2008, at 1:34 PM, Iruata Souza wrote: On Fri, Apr 25, 2008 at 11:25 PM, Ian McWilliam [EMAIL PROTECTED] wrote: Stephan Andre' wrote: On Friday 25 April 2008 20:49:00 Ian McWilliam wrote: Ok, Not really wanting to comment on this call me a troll, call me want you want but The following rant in NOT about GPL licensing. I am neither supporting or denying the the said change to xdpf. This is a discussion about modifying standards.. What is hypocrytical here is the not one person has said the have looked at the standard for PDF to determine the correct behaviour. Whether it is for or against peoples wishes, there is a standard somewhere and even the author of xpdf hints that there is one and what you are removing is against the standard. http://www.foolabs.com/xpdf/cracking.html ... I distribute source code (for Xpdf) under a particular license (the GPL) which depends entirely on users' goodwill for its effectiveness. If any of my users ever decided to violate the license, I would probably never even know about it, much less be able to do anything about it. The only thing I can do is trust the users. In light of this, it would be very hypocritical of me to, on one hand, ask people to honor my licensing restrictions, and, on the other hand, bypass (or assist others in bypassing) another author's requested restrictions. In addition to all of this, Adobe requires that implementors of the PDF spec adhere to the document permissions. ... I haven't read the Adobe PDF sepc or standard and have no intention to. It looks like no body here wants to either. I find that puzzling seeing. According to a recent thread on tech@ recently, http://marc.info/?l=openbsd-techm=120890031123301w=2 This patch is a joke. It will never go into OpenSSH since it is completely incorrect. The standard is clear -- The version string for an SSH client or server is supposed to be disclosed. It is the standard behaviour, and is done for very good reasons. Can anybody explain why is it acceptable to modify a standard for ports but not not for base? flame away Ian McWilliam P.S I hate DRM as much as the next person. Because the two are completely different concepts. The SSH patch was clueless, both in terms of how OpenSSH works, and the protection it would(n't) give. Sorry STeve but we are not talking directly about the SSH patch in question. It's the concept of modifying software away from it's documented behaviour / standard. The removal of the DRM code is has actual benefit, the GPL permits this, and Adobe *knows* this. This is useless laywer gobble. PDF's are now an ISO standard. So if PDF is now an ISO standrard then what does the standard say about what being modified? This still dosn't answer why it is acceptable to modify a piece of software away from it's standards definition maybe you are a little confuse about design versus implementation? iru Not really, I have no issue with design vs implementation as long as it is documented somehow. The issue is that we want to modify software away from the original implementation but not document that fact. Ian McWilliam
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On 26 Apr 2008, at 2:30 PM, Nick Holland wrote: Ian McWilliam wrote: ... Can anybody explain why is it acceptable to modify a standard for ports but not not for base? I think Standards is a bogus argument here. That's not what this is about. Try this way of looking at it: The author of xpdf wants DRM in the source code. That is his right. Many users find it more useful without it. That is their right. We distribute patches to build a version that disables the DRM that will never be incorporated into the main package. That is our right. The author distributes it the way they wish to, and OpenBSD distributes a patch. Everyone's rights are respected. Author has freedom, users have freedom, OpenBSD has freedom. The authors of OpenSSH don't want to hide the version. That is their right. A few users think there is benefit in hiding the version. That is their right (you have the right to remain wrong...) Someone distributes a patch that will never go into the OpenSSH code. That is their right. The authors distribute the code they wish to and users can distribute a patch. Everyone's rights are respected. Authors have freedom, users have freedom, patchers have freedom. You see a difference. I see remarkable parallels. This is real freedom in action. What you seem to think is that you get a vote or claim on someone else's work. No, you don't. Not here, at least. OpenBSD decides what is in OpenBSD, The xpdf authors get to decide what is in xpdf, The OpenSSH authors get to decide what is in OpenSSH. And that is how it should be, and that is how it is. YOU get to decide what you wish to use, too. Not if you modify that software away from it's original intention and not tell me about it. Then I don't get to decide. You may use OpenBSD or not. You may use xpdf in patched or unpatched form. Only if I know it's changed. No body seems prepared to tell me you modified it at point of installation. You may or may not respect the wishes of the author of documents you look at with xpdf. wow, you got freedom too. Amazing how this works. :) Think about this: I suspect most developers and users of OpenBSD think the DRM features of xpdf are stupid and annoying..but I bet virtually all of them would fight for the RIGHT of the author to decide to be stupid and annoying, and put whatever they darned well please into their own code. There is a difference between wishing and attempting to persuade someone to do something differently, and demanding or expecting them to do something differently. A very large difference, which is often missed by many. I WISH xpdf didn't have silly DRM stuff in it. I WISH people didn't distribute silly patches for OpenSSH I am glad they can. Nick. -- By reading this note, you agree to not think of a big red bird with fuzzy pink feet. Ian McWilliam
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
Ian McWilliam [EMAIL PROTECTED] writes: The real issue for me at least is the fact that one is prepared to modify (in this case xpdf) away for what ever standard it is written against, modified away from the original software distribution without documenting the change, informing the end user who installs the modified software so they can make an informed decision as to whether they still want to use the modified version or go off and install the unmodified version. I'd call it a sane default. If we made an xpdf-drm FLAVOR of this port, how many people do you think would choose it? Would you?
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Thu, May 01, 2008 at 08:43:36PM +1000, Ian McWilliam wrote: Finally, some sense, thanks. The real issue for me at least is the fact that one is prepared to modify (in this case xpdf) away for what ever standard it is written against, modified away from the original software distribution without documenting the change, informing the end user who installs the modified software so they can make an informed decision as to whether they still want to use the modified version or go off and install the unmodified version. I don't see any actual reason to have flavors for xpdf. As far as I'm concerned, the drm part is just some bits in the document. This is information, we should display it, let's say add a menu that tells you what protection the document has, possibly add a notice requester that tells you the author didn't intend for you to print the document, asking you for confirmation and... that's it. I only see reasons to tell people they're about to do something that the original author of the document didn't intend them to, and to let them choose what they will do, based on technical possibilities.
Re: DRM in xpdf
Am Fri, 25 Apr 2008 23:25:13 +0200 schrieb Martin Schröder [EMAIL PROTECTED]: 2008/4/25 Deanna Phillips [EMAIL PROTECTED]: For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). Go ahead, ignore the authors wishes. Show your disrespect. The fundamental concept of DRM is flawed. And here is why: In fact this is not about the authors wishes. The author can not disclose content on PDF form or he can choose to encrypt a PDF with some sort of algorithm that is a real encryption. Or he can tell me in the first part of a PDF how he likes me to handle the content of the document or the document itself. DRM on the other side is a mere technical mechanism that FORCES the end user to not be ABLE to use the document in his or her best way. So this is not a wish, it is a senseless blockage. So I think either should people not publish or use mechanisms that really encrypt. Not that ROT13 kind of encryption and also expect the software authors or software distributors to make software dysfunctional just because they wont tell the user what they want (by words or licenses), nor use available technology that does a real encryption and not a pseudo encryption. Maybe authors like their Encrypted documents to be readable by everyone - they just dont want them to be inexed by Google - how are we to know what authors want who dont really tell us what they want nor use technics that make sure nobody can decrypt. If I use very weak encryption one can assume that the decryption is not what I (as an author) dont want at all. Thilo
Re: DRM in xpdf
Am Sat, 26 Apr 2008 01:52:47 +0200 schrieb Paul de Weerd [EMAIL PROTECTED]: Again, please note that the OpenBSD project does not distribute the patched files. Just thinking that it would be saner of the original author if he woul have a configuration switch for disabling. Now everybody does a patch instead of just choosing to compile without. I can accept him not having this on by default though. Thilo
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
Zvezdan Petkovic wrote: On Apr 26, 2008, at 7:30 AM, Marc Espie wrote: If anything, our xpdf should probably display a notice that says `the author of the document thought you should not be able to print it... or whatever'. I didn't mean to get into this discussion because it really doesn't concern me at all. Whatever the port maintainer decides I'm fine with it. However, I agree with this comment above from Marc Espie. I am guilty of using DRM in PDF in the past. Here's my use case. I used to teach at the university. My slides usually had figures with animations in it, resulting in multiple pages for each step of animation. If a student presses a print button in a public lab they may pay a lot of money for 200 pages of slides in huge letters and page-by-page animation. To prevent an unnecessary expense to a student, I always switched ON do not allow printing in PDFs of these lecture slides. I also always posted a 4 up version of the slides with *no* protection -- 4 slides per page with animations turned into a final picture after the last step. Students than could print 10 to 20 pages of this document as opposed to 200. They could also watch original slides on screen if they needed to see steps in the particular figure for better understanding of a process. I also alway explained to students in class why there are two copies of the same slides and why is only one of them printable. So, in my opinion this DRM has its use cases. I hate to disagree with somebody who sounds like my fellow countryman but DRM has NO use. I also teach at the University and I some time prepare slides too which use over layers and even more fancy stuff. Any decant software for preparing slides (in my case I use Powerdot Latex class of presentation) has so called note mode. In note mode you can choose to put up to 4 slides on the single sheet of the paper for purposes of printing hand outs for your students. You may also include additional rule lines for taking the notes. Note mode will ignore over layers (which are in essence separate slides) or any other additional stuff. To stay on the same note I think that scientific publishing is in sorry state and is ripe for a Theo De Raadt of open publishing. I am so sick to see my students spending hundreds of dollars for books that should not cost mode than $10. In an era when the role of publisher is in essence reduced to printing already prepared manuscript (yes TeX and computers have revolutionized publishing almost as much as Gutenberg printing press) and maybe market it little bit I see no reasons for their existence in present form. I am sick of cheap tricks like having new editions every two years or so. I am sick of extra software that comes with the textbooks that nobody uses. I am sadden by a use of high quality paper for books that kids are not going to keep more than a single school year. Most Kind Regards, Predrag Punosevac Replacing a protection with a message of intent of the author is probably a good idea.
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Sun, Apr 27, 2008 at 12:53 AM, Predrag Punosevac [EMAIL PROTECTED] wrote: I hate to disagree with somebody who sounds like my fellow countryman but DRM has NO use. I also teach at the University and I some time prepare slides too which use over layers and even more fancy stuff. Any decant software for preparing slides (in my case I use Powerdot Latex class of presentation) has so called note mode. In note mode you can choose to put up to 4 slides on the single sheet of the paper for purposes of printing hand outs for your students. You may also include additional rule lines for taking the notes. Note mode will ignore over layers (which are in essence separate slides) or any other additional stuff. Zvezdan did say I also always posted a 4 up version of the slides with *no* protection -- 4 slides per page with animations turned into a final picture after the last step. His use case for PDF's DRM was simply to protect students from accidentally printing the animated slides instead of the still 4-up slides.
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Apr 27, 2008, at 12:20 AM, Matthew Dempsky wrote: In lieu of that, a simpler solution would seem to be to title your links to the slides as Printer-friendly sides (no animation) and Screen-friendly slides (animation). Hopefully university students can read, and if not, they should learn quickly after paying for a 200 page printout. :-) Thank you for the comment Matthew. That is exactly what I did. The lecture table on the class web site looked something like this. Lecture title Slides Printable 4 up slides I also agree with you that the message could be too intrusive. I knew that more advanced students who use Linux or BSDs can go around the protection on the slides and I didn't worry about that at all. I simply knew that they know enough to take care of themselves. Best regards, Zvezdan
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
--- Predrag Punosevac [EMAIL PROTECTED] wrote: Zvezdan Petkovic wrote: So, in my opinion this DRM has its use cases. I hate to disagree with somebody who sounds like my fellow countryman but DRM has NO use. Actually, he stated a use for it. Just because there are alternatives doesn't mean that his use isn't valid. To stay on the same note I think that scientific publishing is in sorry state and is ripe for a Theo De Raadt of open publishing. Considering that many researchers post there papers on there own web pages, there is the arXiv, a second (at least) free textbook publisher announced on slashdot a few days ago, department made texts at many Universities (several of my classes had them at my old U) and the existence of places like lulu.com, I don't think that we are in such dire straights as you seem to imply that we are in. All that I think needs to happen is that Profs take advantage of the resources that are already out there. As in, it's one thing for these texts to exist, but quite another for them to be used. But, it does also take man power to create these texts in the first place... I am so sick to see my students spending hundreds of dollars for books that should not cost mode than $10. In an era when the role of publisher is in essence reduced to printing already prepared manuscript (yes TeX and computers have revolutionized publishing almost as much as Gutenberg printing press) and maybe market it little bit I see no reasons for their existence in present form. I am sick of cheap tricks like having new editions every two years or so. In general I agree, but there are some exceptions. For instance, there is Dudley's Elementary Number Theory and Nering's Linear Algebra and Matrix Theory among others (some by Lang and Rudin). All of those worth there high price tag. Let's not ignore corner cases. But, even then, Profs should start to apply pressure to publishing houses to lower the prices of (at least) the older texts. It's not like they haven't recouped the expenses. I am sick of extra software that comes with the textbooks that nobody uses. I am sadden by a use of high quality paper for books that kids are not going to keep more than a single school year. Not to mention the glare that comes off that paper that makes it difficult to read... at least for my older eyes ;) At any rate, so as to not have this mail completely off topic, if the maintainer would include a patch to get rid of the DRM in xpdf, I'd greatly appreciate it. best regards, Reid Nichol President Bush says: War Is Peace Freedom Is Slavery Ignorance Is Strength Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Sat, 26 Apr 2008, Ian McWilliam wrote: Whether it is for or against peoples wishes, there is a standard somewhere and even the author of xpdf hints that there is one and what you are removing is against the standard. Confirmed. And we are happy about it! DRM is in the PDF standard. (Which is bad, but I won't waste time trying to fix that...) OpenBSD is now removing DRM from xpdf. (Which is good.) So instead of being compliant to the full PDF standard, the new OpenBSD version of xpdf will be compliant to the PDF standard, excluding the DRM stuff. (Which is better than full compliance, since we are avoiding a denial-of-service vulnerability in the standard.) This could be worth meantioning in the man page... /Johan
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Sat, 26 Apr 2008, Ian McWilliam wrote: I haven't read the Adobe PDF sepc or standard and have no intention to. It looks like no body here wants to either. I find that puzzling seeing. http://www.mail-archive.com/ports@openbsd.org/msg16457.html The reason those checks are in there are simple: You need to implement these functions to comply to the PDF specs. -- Floor Terra [EMAIL PROTECTED] www: http://brobding.mine.nu/
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
We're talking about stupid, evil, legal DRM here. The pdf document basically says `oh, you're not supposed to do things with this document, because I say so'. There's nothing that prevents anyone from doing anything with the document. If anything, our xpdf should probably display a notice that says `the author of the document thought you should not be able to print it... or whatever'. But there is no actual protection in the document. It's all stupid shackles in software. This is a case where I strongly believe in freedom: the end user should be able to decide what they can do with the document. And equality: knowledgeable technical users shouldn't have an edge. It's completely hypocritical to say `oh, you can recompile the software to remove the restriction', because it shuts down some users. As far as I'm concerned, you've got two levels of protection: legal and technical. This `drm' part of pdf is purely legal: you get a document, you are informed you're not supposed to do such and such, and THAT'S IT. There's no technical protection to speak of. For me, the legal barrier is quite enough. As adult, you can make an ethical choice whether or not to obey the spirit of the document author.
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Sat, 26 Apr 2008, Floor Terra wrote: On Sat, 26 Apr 2008, Ian McWilliam wrote: I haven't read the Adobe PDF sepc or standard and have no intention to. It looks like no body here wants to either. I find that puzzling seeing. http://www.mail-archive.com/ports@openbsd.org/msg16457.html The reason those checks are in there are simple: You need to implement these functions to comply to the PDF specs. Since when does this crowd interpret closed, DRM-embodying legal notice crap as an official spec? DRM has no place in free software. As others pointed out, the legal disclaimers are totally sufficient. Lee == Leland V. Lammert[EMAIL PROTECTED] Chief ScientistOmnitec Corporation Network/Internet Consultants www.omnitec.net ==
Re: DRM in xpdf
On 4/26/08 12:25 AM, Miod Vallat wrote: For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). Go ahead, ignore the authors wishes. Show your disrespect. Your logic implies GPL respects authors. ROFL!!! +++chefren
Re: DRM in xpdf
On 4/26/08 1:23 AM, Martin Schröder wrote: 2008/4/26 Tobias Ulmer [EMAIL PROTECTED]: 2. a) Yup, there it is, complete with dates: http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/xpdf/patches/ The modified file? But I rest my case; 4 lines are not worth the trouble. Ah, principles don't count. One -bit- can be worth the trouble to a big majority here. You are a troll. +++chefren
Re: DRM in xpdf
On 4/26/08 2:56 AM, Travers Buda wrote: The GPL is being followed. DRM is stupid. Oh wait, as a matter of fact, the two are ideologically opposed to each other! No no no, GPL is BSD with DRM. +++chefren
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Apr 26, 2008, at 7:30 AM, Marc Espie wrote: If anything, our xpdf should probably display a notice that says `the author of the document thought you should not be able to print it... or whatever'. I didn't mean to get into this discussion because it really doesn't concern me at all. Whatever the port maintainer decides I'm fine with it. However, I agree with this comment above from Marc Espie. I am guilty of using DRM in PDF in the past. Here's my use case. I used to teach at the university. My slides usually had figures with animations in it, resulting in multiple pages for each step of animation. If a student presses a print button in a public lab they may pay a lot of money for 200 pages of slides in huge letters and page-by-page animation. To prevent an unnecessary expense to a student, I always switched ON do not allow printing in PDFs of these lecture slides. I also always posted a 4 up version of the slides with *no* protection -- 4 slides per page with animations turned into a final picture after the last step. Students than could print 10 to 20 pages of this document as opposed to 200. They could also watch original slides on screen if they needed to see steps in the particular figure for better understanding of a process. I also alway explained to students in class why there are two copies of the same slides and why is only one of them printable. So, in my opinion this DRM has its use cases. Replacing a protection with a message of intent of the author is probably a good idea.
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Sat, Apr 26, 2008 at 6:29 PM, Zvezdan Petkovic [EMAIL PROTECTED] wrote: Replacing a protection with a message of intent of the author is probably a good idea. Maybe for the xpdf maintainer (e.g., a --soft-drm configure option), but that definitely seems way too intrusive a patch for maintainence within the ports tree. In lieu of that, a simpler solution would seem to be to title your links to the slides as Printer-friendly sides (no animation) and Screen-friendly slides (animation). Hopefully university students can read, and if not, they should learn quickly after paying for a 200 page printout. :-)
Re: DRM in xpdf
2008/4/25 Theo de Raadt [EMAIL PROTECTED]: Thank you very much for your opinion, but it is clear you come with an agenda. The OpenBSD project people do not follow the bend to Adobe agenda that some xpdf people follow. While it's always nice to blame Adobe, please first discuss those patches upstream (i.e. with Derek and/or the poppler guys). And then consider forking an OpenXPDF. At least make sure the original author never gets bug reports from your Frankenstein-XPDF. Best Martin
Re: DRM in xpdf
On Friday 25 April 2008 04:00:22 Martin Schröder wrote: 2008/4/25 Theo de Raadt [EMAIL PROTECTED]: Thank you very much for your opinion, but it is clear you come with an agenda. The OpenBSD project people do not follow the bend to Adobe agenda that some xpdf people follow. While it's always nice to blame Adobe, please first discuss those patches upstream (i.e. with Derek and/or the poppler guys). And then consider forking an OpenXPDF. At least make sure the original author never gets bug reports from your Frankenstein-XPDF. The patches will never be accepted upstream and there is no need for a fork at all. What bug reports? OMG! I can read the PDFs. bug bug! Get a clue. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: DRM in xpdf
2008/4/25 Theo de Raadt [EMAIL PROTECTED]: Thank you very much for your opinion, but it is clear you come with an agenda. The OpenBSD project people do not follow the bend to Adobe agenda that some xpdf people follow. While it's always nice to blame Adobe, please first discuss those patches upstream (i.e. with Derek and/or the poppler guys). And then consider forking an OpenXPDF. At least make sure the original author never gets bug reports from your Frankenstein-XPDF. We don't have to do that. And if you don't like what our ports people do, you are more than welcome to not use their work. But you are NOT welcome to tell them what they should do.
Re: DRM in xpdf
On Thu, 24 Apr 2008, [ISO-8859-1] Andrés wrote: On Thu, Apr 24, 2008 at 3:42 PM, Deanna Phillips [EMAIL PROTECTED] wrote: There's some DRM code left in xpdf that prevents me from copying text. This kills it. ok? Please, don't add things like this to the ports tree. It's purpose is to easy installation, no to add customized programs. And a flavor wouldn't count, as a flavor is a customized _compiled_ program, not a program + third party patches. It even makes harder to see what patches are _needed_ to make the program install. Please explain before shooting it down. Removing DRM stuff is *good*, so how does that create a 'flavor'? Lee == Leland V. Lammert[EMAIL PROTECTED] Chief ScientistOmnitec Corporation Network/Internet Consultants www.omnitec.net ==
Re: DRM in xpdf
* Martin Schr?der [EMAIL PROTECTED] [2008-04-25 10:00:22]: 2008/4/25 Theo de Raadt [EMAIL PROTECTED]: Thank you very much for your opinion, but it is clear you come with an agenda. The OpenBSD project people do not follow the bend to Adobe agenda that some xpdf people follow. While it's always nice to blame Adobe, please first discuss those patches upstream (i.e. with Derek and/or the poppler guys). And then consider forking an OpenXPDF. At least make sure the original author never gets bug reports from your Frankenstein-XPDF. Best Martin Oh, puh-lease. It's common practice for a distibution of whatever, be it BSD, linux, etc., to add patches to 3rd party programs--not just to make them compile and work on a platform, but also to change functionality. This is no secret; upstream would be foolish to not consider the platform and patches their software is running on and with if they get a bug report. There is plenty of precedent for this sort of thing. Plus, xpdf is GPL 2, so we're not dealing with some sort of Iceweasel or Apache type malarkey. It's not an issue. -- Travers Buda
Re: DRM in xpdf
Floor Terra [EMAIL PROTECTED] writes:
There are similar checks to prevent printing for example. You
only need to put return 1; in OkToPrint()[1]. It's trivial
to change the source and recompile if you need to.
That is much nicer. Here's a new diff from brad that uses your
method.
Works for me with xpdf, pdf2ps, pdftotext and pdfimages.
anyone, ok?
Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.61
diff -u -p -r1.61 Makefile
--- Makefile19 Apr 2008 07:38:24 - 1.61
+++ Makefile24 Apr 2008 23:06:43 -
@@ -4,8 +4,8 @@ COMMENT-main= PDF viewer for X11
COMMENT-utils= PDF conversion tools
DISTNAME= xpdf-3.02
-PKGNAME-main= xpdf-3.02pl2p3
-PKGNAME-utils= xpdf-utils-3.02pl2p0
+PKGNAME-main= xpdf-3.02pl2p4
+PKGNAME-utils= xpdf-utils-3.02pl2p1
CATEGORIES=textproc x11
MASTER_SITES= ftp://ftp.foolabs.com/pub/xpdf/ \
Index: patches/patch-xpdf_XPDFCore_cc
===
RCS file: patches/patch-xpdf_XPDFCore_cc
diff -N patches/patch-xpdf_XPDFCore_cc
--- patches/patch-xpdf_XPDFCore_cc 30 Mar 2007 04:09:42 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-xpdf_XPDFCore_cc,v 1.4 2007/03/30 04:09:42 ckuethe Exp $
xpdf/XPDFCore.cc.orig Tue Feb 27 22:05:52 2007
-+++ xpdf/XPDFCore.cc Fri Mar 30 00:31:19 2007
-@@ -407,9 +407,6 @@ void XPDFCore::copySelection() {
- int pg;
- double ulx, uly, lrx, lry;
-
-- if (!doc-okToCopy()) {
--return;
-- }
- if (getSelection(pg, ulx, uly, lrx, lry)) {
- //~ for multithreading: need a mutex here
- if (currentSelection) {
Index: patches/patch-xpdf_XPDFViewer_cc
===
RCS file: patches/patch-xpdf_XPDFViewer_cc
diff -N patches/patch-xpdf_XPDFViewer_cc
--- patches/patch-xpdf_XPDFViewer_cc30 Mar 2007 04:09:42 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-$OpenBSD: patch-xpdf_XPDFViewer_cc,v 1.4 2007/03/30 04:09:42 ckuethe Exp $
xpdf/XPDFViewer.cc.origTue Feb 27 22:05:52 2007
-+++ xpdf/XPDFViewer.cc Fri Mar 30 00:31:19 2007
-@@ -3406,11 +3406,6 @@ void XPDFViewer::printPrintCbk(Widget widget, XtPointe
- PSOutputDev *psOut;
-
- doc = viewer-core-getDoc();
-- if (!doc-okToPrint()) {
--error(-1, Printing this document is not allowed.);
--return;
-- }
--
- viewer-core-setBusyCursor(gTrue);
-
- XtVaGetValues(viewer-printWithCmdBtn, XmNset, withCmd, NULL);
Index: patches/patch-xpdf_XRef_cc
===
RCS file: patches/patch-xpdf_XRef_cc
diff -N patches/patch-xpdf_XRef_cc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-xpdf_XRef_cc 24 Apr 2008 23:53:11 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+--- xpdf/XRef.cc.orig Thu Apr 24 19:13:00 2008
xpdf/XRef.cc Thu Apr 24 19:50:06 2008
+@@ -771,19 +771,19 @@ void XRef::setEncryption(int permFlagsA, GBool ownerPa
+ }
+
+ GBool XRef::okToPrint(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permPrint);
++ return (1);
+ }
+
+ GBool XRef::okToChange(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permChange);
++ return (1);
+ }
+
+ GBool XRef::okToCopy(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permCopy);
++ return (1);
+ }
+
+ GBool XRef::okToAddNotes(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permNotes);
++ return (1);
+ }
+
+ Object *XRef::fetch(int num, int gen, Object *obj) {
Index: patches/patch-xpdf_pdfimages_cc
===
RCS file: patches/patch-xpdf_pdfimages_cc
diff -N patches/patch-xpdf_pdfimages_cc
--- patches/patch-xpdf_pdfimages_cc 24 Oct 2003 19:31:57 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-$OpenBSD: patch-xpdf_pdfimages_cc,v 1.1 2003/10/24 19:31:57 brad Exp $
xpdf/pdfimages.cc.orig 2003-10-23 22:57:28.0 -0700
-+++ xpdf/pdfimages.cc 2003-10-23 22:57:36.0 -0700
-@@ -118,13 +118,6 @@ int main(int argc, char *argv[]) {
- goto err1;
- }
-
-- // check for copy permission
-- if (!doc-okToCopy()) {
--error(-1, Copying of images from this document is not allowed.);
--exitCode = 3;
--goto err1;
-- }
--
- // get page range
- if (firstPage 1)
- firstPage = 1;
Index: patches/patch-xpdf_pdftops_cc
===
RCS file: patches/patch-xpdf_pdftops_cc
diff -N patches/patch-xpdf_pdftops_cc
--- patches/patch-xpdf_pdftops_cc 30 Mar 2007 04:09:42 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-$OpenBSD: patch-xpdf_pdftops_cc,v 1.4 2007/03/30 04:09:42 ckuethe Exp $
xpdf/pdftops.cc.orig Tue Feb
Re: DRM in xpdf
Martin Schröder [EMAIL PROTECTED] writes: 2008/4/25 Deanna Phillips [EMAIL PROTECTED]: anyone, ok? http://www.foolabs.com/xpdf/cracking.html You mean this part? For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this).
Re: DRM in xpdf
Kill the DRM! DIE DIE DIE
In theory, around Friday 25 April 2008 10:22:42 Deanna Phillips wrote:
Floor Terra [EMAIL PROTECTED] writes:
There are similar checks to prevent printing for example. You
only need to put return 1; in OkToPrint()[1]. It's trivial
to change the source and recompile if you need to.
That is much nicer. Here's a new diff from brad that uses your
method.
Works for me with xpdf, pdf2ps, pdftotext and pdfimages.
anyone, ok?
Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.61
diff -u -p -r1.61 Makefile
--- Makefile 19 Apr 2008 07:38:24 - 1.61
+++ Makefile 24 Apr 2008 23:06:43 -
@@ -4,8 +4,8 @@ COMMENT-main= PDF viewer for X11
COMMENT-utils= PDF conversion tools
DISTNAME=xpdf-3.02
-PKGNAME-main=xpdf-3.02pl2p3
-PKGNAME-utils= xpdf-utils-3.02pl2p0
+PKGNAME-main=xpdf-3.02pl2p4
+PKGNAME-utils= xpdf-utils-3.02pl2p1
CATEGORIES= textproc x11
MASTER_SITES=ftp://ftp.foolabs.com/pub/xpdf/ \
Index: patches/patch-xpdf_XPDFCore_cc
===
RCS file: patches/patch-xpdf_XPDFCore_cc
diff -N patches/patch-xpdf_XPDFCore_cc
--- patches/patch-xpdf_XPDFCore_cc30 Mar 2007 04:09:42 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-xpdf_XPDFCore_cc,v 1.4 2007/03/30 04:09:42 ckuethe Exp $
xpdf/XPDFCore.cc.origTue Feb 27 22:05:52 2007
-+++ xpdf/XPDFCore.cc Fri Mar 30 00:31:19 2007
-@@ -407,9 +407,6 @@ void XPDFCore::copySelection() {
- int pg;
- double ulx, uly, lrx, lry;
-
-- if (!doc-okToCopy()) {
--return;
-- }
- if (getSelection(pg, ulx, uly, lrx, lry)) {
- //~ for multithreading: need a mutex here
- if (currentSelection) {
Index: patches/patch-xpdf_XPDFViewer_cc
===
RCS file: patches/patch-xpdf_XPDFViewer_cc
diff -N patches/patch-xpdf_XPDFViewer_cc
--- patches/patch-xpdf_XPDFViewer_cc 30 Mar 2007 04:09:42 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-$OpenBSD: patch-xpdf_XPDFViewer_cc,v 1.4 2007/03/30 04:09:42 ckuethe Exp $
xpdf/XPDFViewer.cc.orig Tue Feb 27 22:05:52 2007
-+++ xpdf/XPDFViewer.cc Fri Mar 30 00:31:19 2007
-@@ -3406,11 +3406,6 @@ void XPDFViewer::printPrintCbk(Widget widget,
XtPointe - PSOutputDev *psOut;
-
- doc = viewer-core-getDoc();
-- if (!doc-okToPrint()) {
--error(-1, Printing this document is not allowed.);
--return;
-- }
--
- viewer-core-setBusyCursor(gTrue);
-
- XtVaGetValues(viewer-printWithCmdBtn, XmNset, withCmd, NULL);
Index: patches/patch-xpdf_XRef_cc
===
RCS file: patches/patch-xpdf_XRef_cc
diff -N patches/patch-xpdf_XRef_cc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-xpdf_XRef_cc24 Apr 2008 23:53:11 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+--- xpdf/XRef.cc.origThu Apr 24 19:13:00 2008
xpdf/XRef.cc Thu Apr 24 19:50:06 2008
+@@ -771,19 +771,19 @@ void XRef::setEncryption(int permFlagsA, GBool
ownerPa + }
+
+ GBool XRef::okToPrint(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permPrint);
++ return (1);
+ }
+
+ GBool XRef::okToChange(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permChange);
++ return (1);
+ }
+
+ GBool XRef::okToCopy(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permCopy);
++ return (1);
+ }
+
+ GBool XRef::okToAddNotes(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permNotes);
++ return (1);
+ }
+
+ Object *XRef::fetch(int num, int gen, Object *obj) {
Index: patches/patch-xpdf_pdfimages_cc
===
RCS file: patches/patch-xpdf_pdfimages_cc
diff -N patches/patch-xpdf_pdfimages_cc
--- patches/patch-xpdf_pdfimages_cc 24 Oct 2003 19:31:57 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-$OpenBSD: patch-xpdf_pdfimages_cc,v 1.1 2003/10/24 19:31:57 brad Exp $
xpdf/pdfimages.cc.orig 2003-10-23 22:57:28.0 -0700
-+++ xpdf/pdfimages.cc2003-10-23 22:57:36.0 -0700
-@@ -118,13 +118,6 @@ int main(int argc, char *argv[]) {
- goto err1;
- }
-
-- // check for copy permission
-- if (!doc-okToCopy()) {
--error(-1, Copying of images from this document is not allowed.);
--exitCode = 3;
--goto err1;
-- }
--
- // get page range
- if (firstPage 1)
- firstPage = 1;
Index: patches/patch-xpdf_pdftops_cc
===
RCS file: patches/patch-xpdf_pdftops_cc
diff -N patches/patch-xpdf_pdftops_cc
Re: DRM in xpdf
* Martin Schr?der [EMAIL PROTECTED] [2008-04-25 17:32:26]: 2008/4/25 Travers Buda [EMAIL PROTECTED]: There is plenty of precedent for this sort of thing. Plus, xpdf is GPL 2, so we're not dealing with some sort of Iceweasel or Apache type malarkey. It's not an issue. Read section 2 of the GPL2 please. Best Martin This part? You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications... Apache, in my example, added some sort of clause that you can't modify / distribute their software and call it apache. That's not the GPL, that's their own clause. It's the rebranding issue. It does not exist with xpdf. But really, the rebranding issue is not germane to this discussion; there's no need to fork the software. That would be the only time I would consider such action. -- Travers Buda
Re: DRM in xpdf
On Fri, Apr 25, 2008 at 8:22 AM, Deanna Phillips
[EMAIL PROTECTED] wrote:
Floor Terra [EMAIL PROTECTED] writes:
There are similar checks to prevent printing for example. You
only need to put return 1; in OkToPrint()[1]. It's trivial
to change the source and recompile if you need to.
That is much nicer. Here's a new diff from brad that uses your
method.
Works for me with xpdf, pdf2ps, pdftotext and pdfimages.
anyone, ok?
Go for it.
Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.61
diff -u -p -r1.61 Makefile
--- Makefile19 Apr 2008 07:38:24 - 1.61
+++ Makefile24 Apr 2008 23:06:43 -
@@ -4,8 +4,8 @@ COMMENT-main= PDF viewer for X11
COMMENT-utils= PDF conversion tools
DISTNAME= xpdf-3.02
-PKGNAME-main= xpdf-3.02pl2p3
-PKGNAME-utils= xpdf-utils-3.02pl2p0
+PKGNAME-main= xpdf-3.02pl2p4
+PKGNAME-utils= xpdf-utils-3.02pl2p1
CATEGORIES=textproc x11
MASTER_SITES= ftp://ftp.foolabs.com/pub/xpdf/ \
Index: patches/patch-xpdf_XPDFCore_cc
===
RCS file: patches/patch-xpdf_XPDFCore_cc
diff -N patches/patch-xpdf_XPDFCore_cc
--- patches/patch-xpdf_XPDFCore_cc 30 Mar 2007 04:09:42 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-xpdf_XPDFCore_cc,v 1.4 2007/03/30 04:09:42 ckuethe Exp $
xpdf/XPDFCore.cc.orig Tue Feb 27 22:05:52 2007
-+++ xpdf/XPDFCore.cc Fri Mar 30 00:31:19 2007
-@@ -407,9 +407,6 @@ void XPDFCore::copySelection() {
- int pg;
- double ulx, uly, lrx, lry;
-
-- if (!doc-okToCopy()) {
--return;
-- }
- if (getSelection(pg, ulx, uly, lrx, lry)) {
- //~ for multithreading: need a mutex here
- if (currentSelection) {
Index: patches/patch-xpdf_XPDFViewer_cc
===
RCS file: patches/patch-xpdf_XPDFViewer_cc
diff -N patches/patch-xpdf_XPDFViewer_cc
--- patches/patch-xpdf_XPDFViewer_cc30 Mar 2007 04:09:42 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-$OpenBSD: patch-xpdf_XPDFViewer_cc,v 1.4 2007/03/30 04:09:42 ckuethe Exp $
xpdf/XPDFViewer.cc.origTue Feb 27 22:05:52 2007
-+++ xpdf/XPDFViewer.cc Fri Mar 30 00:31:19 2007
-@@ -3406,11 +3406,6 @@ void XPDFViewer::printPrintCbk(Widget widget,
XtPointe
- PSOutputDev *psOut;
-
- doc = viewer-core-getDoc();
-- if (!doc-okToPrint()) {
--error(-1, Printing this document is not allowed.);
--return;
-- }
--
- viewer-core-setBusyCursor(gTrue);
-
- XtVaGetValues(viewer-printWithCmdBtn, XmNset, withCmd, NULL);
Index: patches/patch-xpdf_XRef_cc
===
RCS file: patches/patch-xpdf_XRef_cc
diff -N patches/patch-xpdf_XRef_cc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-xpdf_XRef_cc 24 Apr 2008 23:53:11 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+--- xpdf/XRef.cc.orig Thu Apr 24 19:13:00 2008
xpdf/XRef.cc Thu Apr 24 19:50:06 2008
+@@ -771,19 +771,19 @@ void XRef::setEncryption(int permFlagsA, GBool ownerPa
+ }
+
+ GBool XRef::okToPrint(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permPrint);
++ return (1);
+ }
+
+ GBool XRef::okToChange(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permChange);
++ return (1);
+ }
+
+ GBool XRef::okToCopy(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permCopy);
++ return (1);
+ }
+
+ GBool XRef::okToAddNotes(GBool ignoreOwnerPW) {
+- return (!ignoreOwnerPW ownerPasswordOk) || (permFlags permNotes);
++ return (1);
+ }
+
+ Object *XRef::fetch(int num, int gen, Object *obj) {
Index: patches/patch-xpdf_pdfimages_cc
===
RCS file: patches/patch-xpdf_pdfimages_cc
diff -N patches/patch-xpdf_pdfimages_cc
--- patches/patch-xpdf_pdfimages_cc 24 Oct 2003 19:31:57 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-$OpenBSD: patch-xpdf_pdfimages_cc,v 1.1 2003/10/24 19:31:57 brad Exp $
xpdf/pdfimages.cc.orig 2003-10-23 22:57:28.0 -0700
-+++ xpdf/pdfimages.cc 2003-10-23 22:57:36.0 -0700
-@@ -118,13 +118,6 @@ int main(int argc, char *argv[]) {
- goto err1;
- }
-
-- // check for copy permission
-- if (!doc-okToCopy()) {
--error(-1, Copying of images from this document is not allowed.);
--exitCode = 3;
--goto err1;
-- }
--
- // get page range
- if (firstPage 1)
- firstPage = 1;
Index: patches/patch-xpdf_pdftops_cc
Re: DRM in xpdf
2008/4/25 Travers Buda [EMAIL PROTECTED]: This part? Troll.
Re: DRM in xpdf
2008/4/25 Deanna Phillips [EMAIL PROTECTED]: For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). Go ahead, ignore the authors wishes. Show your disrespect. Best Martin
Re: DRM in xpdf
* Martin Schr?der [EMAIL PROTECTED] [2008-04-25 23:23:17]: 2008/4/25 Travers Buda [EMAIL PROTECTED]: This part? Troll. Wow. -- Travers Buda
Re: DRM in xpdf
2008/4/25 Deanna Phillips [EMAIL PROTECTED]: You mean this part? For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). While an XPDF port with these patches is technically not distributed but compiled by the user installing the port, any package of this patched XPDF will be a modified version of XPDF and as such has to follow the restrictions on distributing modified programs as specified in section 2 of the GPL. Or you stop distributing XPDF packages. My god you have an utterly twisted view on what free means. Why don't you just get lost. You are completely wrong.
Re: DRM in xpdf
On Fri, Apr 25, 2008 at 11:25:13PM +0200, Martin Schr?der wrote: 2008/4/25 Deanna Phillips [EMAIL PROTECTED]: For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). Go ahead, ignore the authors wishes. Show your disrespect. Author has *wished* that his software source code be available for anyone to modify it orelse he would not have released it under the GPL. Gilles -- Gilles Chehade http://www.poolp.org/
Re: DRM in xpdf
On Fri, Apr 25, 2008 at 11:25:13PM +0200, Martin Schröder wrote: For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). Go ahead, ignore the authors wishes. Show your disrespect. He chooses GPLv2. We're allowed to modify his code. So what? I'm pretty sure Derek is aware of patches disabling that DRM shit. Probably he just don't want to be blamed by Adobe. Heck, patching away that DRM joke for PDF wouldn't even apply to the shiny new german law against hacker tools. Ciao, Kili -- Are there any plans on increasing this? not this week. -- Travis Gillitzer and Ted Unangst on [EMAIL PROTECTED]
Re: DRM in xpdf
For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). Go ahead, ignore the authors wishes. Show your disrespect. Your logic implies GPL respects authors. Miod
Re: DRM in xpdf
On Fri, Apr 25, 2008 at 10:16:48PM +, Miod Vallat wrote: For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). Go ahead, ignore the authors wishes. Show your disrespect. Your logic implies GPL respects authors. Uh oh ... the showerless happy hacker will come and hunt you now ... :-) -- Gilles Chehade http://www.poolp.org/
Re: DRM in xpdf
2008/4/26 Marco Peereboom [EMAIL PROTECTED]: Huh? The wishes are gpl; the patch is available so all gpl requirements have been met. Why in the world is this being debated? If your logic was true all linux distributions would be breaking the rules because everyone patches stuff. How did you even come up with this? Have you read section 2 of the GPL lately? I agree that for normal patches (security fixes etc.) this is not an issue - but only because nobody cares. These patches still create modified versions, but it's a gray area. I argue that the anti-DRM patch is not a normal patch as stated above but goes further and as such creates a modified version were you must follow secion 2. It boils down to: When is a modification large enough so that section 2 applies? Best Martin
Re: DRM in xpdf
On Fri, Apr 25, 2008 at 6:25 PM, Martin Schröder [EMAIL PROTECTED] wrote: 2008/4/25 Deanna Phillips [EMAIL PROTECTED]: For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). Go ahead, ignore the authors wishes. Show your disrespect. stop writing e-mails then. your mail app was not designed to permit such crap you write to be distributed. iru
Re: DRM in xpdf
On Fri, Apr 25, 2008 at 7:43 PM, Martin Schröder [EMAIL PROTECTED] wrote: 2008/4/26 Marco Peereboom [EMAIL PROTECTED]: Huh? The wishes are gpl; the patch is available so all gpl requirements have been met. Why in the world is this being debated? If your logic was true all linux distributions would be breaking the rules because everyone patches stuff. How did you even come up with this? Have you read section 2 of the GPL lately? I agree that for normal patches (security fixes etc.) this is not an issue - but only because nobody cares. These patches still create modified versions, but it's a gray area. I argue that the anti-DRM patch is not a normal patch as stated above but goes further and as such creates a modified version were you must follow secion 2. It boils down to: When is a modification large enough so that section 2 applies? It boils down to: When will Martin stop writing such crap showing his disrespect for his mail app's authors? iru
Re: DRM in xpdf
On Sat, Apr 26, 2008 at 12:43:42AM +0200, Martin Schr?der wrote: 2008/4/26 Marco Peereboom [EMAIL PROTECTED]: Huh? The wishes are gpl; the patch is available so all gpl requirements have been met. Why in the world is this being debated? If your logic was true all linux distributions would be breaking the rules because everyone patches stuff. How did you even come up with this? Have you read section 2 of the GPL lately? I agree that for normal patches (security fixes etc.) this is not an issue - but only because nobody cares. These patches still create modified versions, but it's a gray area. I argue that the anti-DRM patch is not a normal patch as stated above but goes further and as such creates a modified version were you must follow secion 2. It boils down to: When is a modification large enough so that section 2 applies? Best Martin 2. a) Yup, there it is, complete with dates: http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/xpdf/patches/ b) Yup, we don't want monies for it. c) Not interactive/doesn't apply. Tobias
Re: DRM in xpdf
2008/4/26 Tobias Ulmer [EMAIL PROTECTED]: 2. a) Yup, there it is, complete with dates: http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/xpdf/patches/ The modified file? But I rest my case; 4 lines are not worth the trouble. Best Martin
Re: DRM in xpdf
On Sat, Apr 26, 2008 at 12:43:42AM +0200, Martin Schr?der wrote: | 2008/4/26 Marco Peereboom [EMAIL PROTECTED]: | Huh? The wishes are gpl; the patch is available so all gpl requirements | have been met. Why in the world is this being debated? | | If your logic was true all linux distributions would be breaking the | rules because everyone patches stuff. How did you even come up with | this? | | Have you read section 2 of the GPL lately? Just did, actually. | I agree that for normal patches (security fixes etc.) this is not an | issue - but only because nobody cares. These patches still create | modified versions, but it's a gray area. I'm not quite sure how you can defend this being a gray area. Changing the code, gives a modified version. Changing indentation may be a gray area, but actual code changes are not. Note that the modified version of the code is not distributed as such. The portstree contains a patch to change the original distributed sources, meeting condition a) of section 2 of the GPL. Condition b) also is met (which is quite obvious). In this specific case, nothing is changed about announcements for interactive use etc, so condition c) is also met. | I argue that the anti-DRM patch is not a normal patch as stated | above but goes further and as such creates a modified version were you | must follow secion 2. It is indeed modified, it offers (in this case) more functionality to the user. However, since the three requirements from section 2 are all met, I see no issue. | It boils down to: When is a modification large enough so that section | 2 applies? Simply be careful, assume that any modification is large enough for section 2 to apply. As long as you meet the three requirements, you're golden. If you disagree (which I fear), could you please state what part of section 2 you are actually referring to ? What is the problem according to you ? Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: DRM in xpdf
2008/4/26 Paul de Weerd [EMAIL PROTECTED]: golden. If you disagree (which I fear), could you please state what part of section 2 you are actually referring to ? What is the problem according to you ? a) wants the notion in the modified file, i.e. the patch should also add a note to the file patched. Otherwise you can not distribute the patched files, but only the original sources plus patches plus instructions (i.e. ports). Best Martin
Re: DRM in xpdf
On Sat, Apr 26, 2008 at 01:26:53AM +0200, Martin Schr?der wrote: | 2008/4/26 Paul de Weerd [EMAIL PROTECTED]: | golden. If you disagree (which I fear), could you please state what | part of section 2 you are actually referring to ? What is the problem | according to you ? | | a) wants the notion in the modified file, i.e. the patch should also | add a note to the file patched. Otherwise you can not distribute the | patched files, but only the original sources plus patches plus | instructions (i.e. ports). That is what the portstree does. So what file is modified, exactly ? The binary ? There is no unmodified binary to begin with, it was compiled and packaged from the portstree. Also, if the patch would add a comment detailing what the patche changes, this comment would not end up in the compiled binary. Specifically separating patches from the (unmodified) source makes these patches quite clearly and prominently notices stating that you changed the [original] files. If you have a close look at the patch files themselves, you'll see specific dates (even times) of these changes. So even if your interpretation of the GPL is correct (which I'm not denying nor confirming), the portstree and packages are in compliance. Again, please note that the OpenBSD project does not distribute the patched files. Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: DRM in xpdf
* Martin Schr?der [EMAIL PROTECTED] [2008-04-25 23:33:05]: 2008/4/25 Deanna Phillips [EMAIL PROTECTED]: You mean this part? For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). While an XPDF port with these patches is technically not distributed but compiled by the user installing the port, any package of this patched XPDF will be a modified version of XPDF and as such has to follow the restrictions on distributing modified programs as specified in section 2 of the GPL. Or you stop distributing XPDF packages. Best Martin You're out of touch with reality. The GPL is not being violated, or even streched for that matter! And whether or not the ports guys remove this drm crap, well, that's not your decision. The DRM is going away. It's absurd to have it. If you can view a document or whatnot, you can copy it. This is some kludge to try and make it harder to do that. Well, honestly, its not that hard. I could type out something by hand in the document or screenshot the images. This is _NOT_ security. It's stupidity. This no-copy crap makes no sense. I can't think of one reason why someone would want this. It's not going to protect the pdf author's work. Which is absurd in its own right. Protecting your work from the very people you are sharing it with. I thought the point of a portable document format was to disseminate information! You keep blabbering on about section 2 of the GPL. Well, we're not changing the license, and the program does not print a license clause on startup, so that only leaves part A: You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. I don't see what's more conducive to this than the nice unified diffs existing in the ports tree. The GPL is being followed. DRM is stupid. Oh wait, as a matter of fact, the two are ideologically opposed to each other! Get a grip. -- Travers Buda
Modifying software written to a Standards document - was Re: DRM in xpdf
Ok, Not really wanting to comment on this call me a troll, call me want you want but The following rant in NOT about GPL licensing. I am neither supporting or denying the the said change to xdpf. This is a discussion about modifying standards.. What is hypocrytical here is the not one person has said the have looked at the standard for PDF to determine the correct behaviour. Whether it is for or against peoples wishes, there is a standard somewhere and even the author of xpdf hints that there is one and what you are removing is against the standard. http://www.foolabs.com/xpdf/cracking.html ... I distribute source code (for Xpdf) under a particular license (the GPL) which depends entirely on users' goodwill for its effectiveness. If any of my users ever decided to violate the license, I would probably never even know about it, much less be able to do anything about it. The only thing I can do is trust the users. In light of this, it would be very hypocritical of me to, on one hand, ask people to honor my licensing restrictions, and, on the other hand, bypass (or assist others in bypassing) another author's requested restrictions. In addition to all of this, Adobe requires that implementors of the PDF spec adhere to the document permissions. ... I haven't read the Adobe PDF sepc or standard and have no intention to. It looks like no body here wants to either. I find that puzzling seeing. According to a recent thread on tech@ recently, http://marc.info/?l=openbsd-techm=120890031123301w=2 This patch is a joke. It will never go into OpenSSH since it is completely incorrect. The standard is clear -- The version string for an SSH client or server is supposed to be disclosed. It is the standard behaviour, and is done for very good reasons. Can anybody explain why is it acceptable to modify a standard for ports but not not for base? flame away Ian McWilliam P.S I hate DRM as much as the next person.
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Friday 25 April 2008 20:49:00 Ian McWilliam wrote: Ok, Not really wanting to comment on this call me a troll, call me want you want but The following rant in NOT about GPL licensing. I am neither supporting or denying the the said change to xdpf. This is a discussion about modifying standards.. What is hypocrytical here is the not one person has said the have looked at the standard for PDF to determine the correct behaviour. Whether it is for or against peoples wishes, there is a standard somewhere and even the author of xpdf hints that there is one and what you are removing is against the standard. http://www.foolabs.com/xpdf/cracking.html ... I distribute source code (for Xpdf) under a particular license (the GPL) which depends entirely on users' goodwill for its effectiveness. If any of my users ever decided to violate the license, I would probably never even know about it, much less be able to do anything about it. The only thing I can do is trust the users. In light of this, it would be very hypocritical of me to, on one hand, ask people to honor my licensing restrictions, and, on the other hand, bypass (or assist others in bypassing) another author's requested restrictions. In addition to all of this, Adobe requires that implementors of the PDF spec adhere to the document permissions. ... I haven't read the Adobe PDF sepc or standard and have no intention to. It looks like no body here wants to either. I find that puzzling seeing. According to a recent thread on tech@ recently, http://marc.info/?l=openbsd-techm=120890031123301w=2 This patch is a joke. It will never go into OpenSSH since it is completely incorrect. The standard is clear -- The version string for an SSH client or server is supposed to be disclosed. It is the standard behaviour, and is done for very good reasons. Can anybody explain why is it acceptable to modify a standard for ports but not not for base? flame away Ian McWilliam P.S I hate DRM as much as the next person. Because the two are completely different concepts. The SSH patch was clueless, both in terms of how OpenSSH works, and the protection it would(n't) give. The removal of the DRM code is has actual benefit, the GPL permits this, and Adobe *knows* this. This is useless laywer gobble. PDF's are now an ISO standard. Apples and oranges. --STeve Andre'
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Fri, Apr 25, 2008 at 5:49 PM, Ian McWilliam [EMAIL PROTECTED] wrote: Can anybody explain why is it acceptable to modify a standard for ports but not not for base? I'm going to guess that the core reason is what helps more users?: - A pdf spec that's written to sell the illusion that you still have control over data that you've given to someone else? That's not helpful, may even be harmful. Insert bad-crypto vs. no-crypto argument... - A pdf reader that gets in the way of you accessing content or a pdf reader that lets you get your job done with the minimum of hassle? The latter. I'm going to assume that if you're looking at a PDF you have at least some license to access it. At least the password protected pdfs make you work for it if you're trying to read a pdf without permission. A non-printable pdf can be trivially screencapped and printed... more illusions for sale. And what if i'm writing a driver based on something in a de-permitted pdf? How is the magic 0x8000 I typed any different from the 0x8000 I could've just copied from the datasheet? - An ssh implementation that tries to avoid known (possibly security-related) bugs or an ssh implementation that just hopes the other guy got it right too. The former is more helpful. Maybe you'll be lucky and negotiate secure settings, maybe you'll be slightly unlucky and fail to connect or maybe you'll be very unlucky and negotiate cipher none. Also, (and this may seem a little shallow) the original implementers (ssh, xpdf, whatever else) probably try to adhere to the spec as closely as they can. They produce a program with predictable behaviour - that's helpful. Then they give away the source in hopes that someone finds it useful... after that, there's nothing stopping their users who've legitimately acquired the source from saying this is 99.% of what i need, i just need one more tweak and hacking it up to suit their own ends. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Friday, April 25, Chris Kuethe wrote: On Fri, Apr 25, 2008 at 5:49 PM, Ian McWilliam [EMAIL PROTECTED] wrote: Can anybody explain why is it acceptable to modify a standard for ports but not not for base? I'm going to guess that the core reason is what helps more users?: Nah, it' because it's right. There are other places where openbsd does not follow the letter of the standard/spec in order to enhance security, or interoperability, or user experience. If a user disagrees, they are welcome to use other software. I certainly won't stop them. :) --Toby.
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
Stephan Andre' wrote: On Friday 25 April 2008 20:49:00 Ian McWilliam wrote: Ok, Not really wanting to comment on this call me a troll, call me want you want but The following rant in NOT about GPL licensing. I am neither supporting or denying the the said change to xdpf. This is a discussion about modifying standards.. What is hypocrytical here is the not one person has said the have looked at the standard for PDF to determine the correct behaviour. Whether it is for or against peoples wishes, there is a standard somewhere and even the author of xpdf hints that there is one and what you are removing is against the standard. http://www.foolabs.com/xpdf/cracking.html ... I distribute source code (for Xpdf) under a particular license (the GPL) which depends entirely on users' goodwill for its effectiveness. If any of my users ever decided to violate the license, I would probably never even know about it, much less be able to do anything about it. The only thing I can do is trust the users. In light of this, it would be very hypocritical of me to, on one hand, ask people to honor my licensing restrictions, and, on the other hand, bypass (or assist others in bypassing) another author's requested restrictions. In addition to all of this, Adobe requires that implementors of the PDF spec adhere to the document permissions. ... I haven't read the Adobe PDF sepc or standard and have no intention to. It looks like no body here wants to either. I find that puzzling seeing. According to a recent thread on tech@ recently, http://marc.info/?l=openbsd-techm=120890031123301w=2 This patch is a joke. It will never go into OpenSSH since it is completely incorrect. The standard is clear -- The version string for an SSH client or server is supposed to be disclosed. It is the standard behaviour, and is done for very good reasons. Can anybody explain why is it acceptable to modify a standard for ports but not not for base? flame away Ian McWilliam P.S I hate DRM as much as the next person. Because the two are completely different concepts. The SSH patch was clueless, both in terms of how OpenSSH works, and the protection it would(n't) give. Sorry STeve but we are not talking directly about the SSH patch in question. It's the concept of modifying software away from it's documented behaviour / standard. The removal of the DRM code is has actual benefit, the GPL permits this, and Adobe *knows* this. This is useless laywer gobble. PDF's are now an ISO standard. So if PDF is now an ISO standrard then what does the standard say about what being modified? This still dosn't answer why it is acceptable to modify a piece of software away from it's standards definition Apples and oranges. --STeve Andre' Another example. Why has the 100 character limit filenames stored in a tar archive not been modified away from its documented standard. (We all know it's 100 character limit is arcane in modern terms. So far no one is coming up with well documented valid arguments for modifying away from documented standards. Ian McWilliam
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Saturday, April 26, Ian McWilliam wrote: Why has the 100 character limit filenames stored in a tar archive not been modified away from its documented standard. (We all know it's 100 character limit is arcane in modern terms. Please use google and find out what gnu tar has done in this area. --Toby.
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
On Fri, Apr 25, 2008 at 11:25 PM, Ian McWilliam [EMAIL PROTECTED] wrote: Stephan Andre' wrote: On Friday 25 April 2008 20:49:00 Ian McWilliam wrote: Ok, Not really wanting to comment on this call me a troll, call me want you want but The following rant in NOT about GPL licensing. I am neither supporting or denying the the said change to xdpf. This is a discussion about modifying standards.. What is hypocrytical here is the not one person has said the have looked at the standard for PDF to determine the correct behaviour. Whether it is for or against peoples wishes, there is a standard somewhere and even the author of xpdf hints that there is one and what you are removing is against the standard. http://www.foolabs.com/xpdf/cracking.html ... I distribute source code (for Xpdf) under a particular license (the GPL) which depends entirely on users' goodwill for its effectiveness. If any of my users ever decided to violate the license, I would probably never even know about it, much less be able to do anything about it. The only thing I can do is trust the users. In light of this, it would be very hypocritical of me to, on one hand, ask people to honor my licensing restrictions, and, on the other hand, bypass (or assist others in bypassing) another author's requested restrictions. In addition to all of this, Adobe requires that implementors of the PDF spec adhere to the document permissions. ... I haven't read the Adobe PDF sepc or standard and have no intention to. It looks like no body here wants to either. I find that puzzling seeing. According to a recent thread on tech@ recently, http://marc.info/?l=openbsd-techm=120890031123301w=2 This patch is a joke. It will never go into OpenSSH since it is completely incorrect. The standard is clear -- The version string for an SSH client or server is supposed to be disclosed. It is the standard behaviour, and is done for very good reasons. Can anybody explain why is it acceptable to modify a standard for ports but not not for base? flame away Ian McWilliam P.S I hate DRM as much as the next person. Because the two are completely different concepts. The SSH patch was clueless, both in terms of how OpenSSH works, and the protection it would(n't) give. Sorry STeve but we are not talking directly about the SSH patch in question. It's the concept of modifying software away from it's documented behaviour / standard. The removal of the DRM code is has actual benefit, the GPL permits this, and Adobe *knows* this. This is useless laywer gobble. PDF's are now an ISO standard. So if PDF is now an ISO standrard then what does the standard say about what being modified? This still dosn't answer why it is acceptable to modify a piece of software away from it's standards definition maybe you are a little confuse about design versus implementation? iru
Re: Modifying software written to a Standards document - was Re: DRM in xpdf
Ian McWilliam wrote: ... Can anybody explain why is it acceptable to modify a standard for ports but not not for base? I think Standards is a bogus argument here. That's not what this is about. Try this way of looking at it: The author of xpdf wants DRM in the source code. That is his right. Many users find it more useful without it. That is their right. We distribute patches to build a version that disables the DRM that will never be incorporated into the main package. That is our right. The author distributes it the way they wish to, and OpenBSD distributes a patch. Everyone's rights are respected. Author has freedom, users have freedom, OpenBSD has freedom. The authors of OpenSSH don't want to hide the version. That is their right. A few users think there is benefit in hiding the version. That is their right (you have the right to remain wrong...) Someone distributes a patch that will never go into the OpenSSH code. That is their right. The authors distribute the code they wish to and users can distribute a patch. Everyone's rights are respected. Authors have freedom, users have freedom, patchers have freedom. You see a difference. I see remarkable parallels. This is real freedom in action. What you seem to think is that you get a vote or claim on someone else's work. No, you don't. Not here, at least. OpenBSD decides what is in OpenBSD, The xpdf authors get to decide what is in xpdf, The OpenSSH authors get to decide what is in OpenSSH. And that is how it should be, and that is how it is. YOU get to decide what you wish to use, too. You may use OpenBSD or not. You may use xpdf in patched or unpatched form. You may or may not respect the wishes of the author of documents you look at with xpdf. wow, you got freedom too. Amazing how this works. :) Think about this: I suspect most developers and users of OpenBSD think the DRM features of xpdf are stupid and annoying..but I bet virtually all of them would fight for the RIGHT of the author to decide to be stupid and annoying, and put whatever they darned well please into their own code. There is a difference between wishing and attempting to persuade someone to do something differently, and demanding or expecting them to do something differently. A very large difference, which is often missed by many. I WISH xpdf didn't have silly DRM stuff in it. I WISH people didn't distribute silly patches for OpenSSH I am glad they can. Nick. -- By reading this note, you agree to not think of a big red bird with fuzzy pink feet.
DRM in xpdf
There's some DRM code left in xpdf that prevents me from copying
text.
This kills it. ok?
Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.61
diff -u -p -r1.61 Makefile
--- Makefile19 Apr 2008 07:38:24 - 1.61
+++ Makefile24 Apr 2008 15:11:09 -
@@ -4,7 +4,7 @@ COMMENT-main= PDF viewer for X11
COMMENT-utils= PDF conversion tools
DISTNAME= xpdf-3.02
-PKGNAME-main= xpdf-3.02pl2p3
+PKGNAME-main= xpdf-3.02pl2p4
PKGNAME-utils= xpdf-utils-3.02pl2p0
CATEGORIES=textproc x11
Index: patches/patch-xpdf_PDFCore_cc
===
RCS file: patches/patch-xpdf_PDFCore_cc
diff -N patches/patch-xpdf_PDFCore_cc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-xpdf_PDFCore_cc 24 Apr 2008 15:09:49 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+--- xpdf/PDFCore.cc.orig Thu Apr 24 11:06:47 2008
xpdf/PDFCore.ccThu Apr 24 11:08:52 2008
+@@ -1563,9 +1563,6 @@ GString *PDFCore::extractText(int pg, double xMin, dou
+ int x0, y0, x1, y1, t;
+ GString *s;
+
+- if (!doc-okToCopy()) {
+-return NULL;
+- }
+ if ((page = findPage(pg))) {
+ cvtUserToDev(pg, xMin, yMin, x0, y0);
+ cvtUserToDev(pg, xMax, yMax, x1, y1);
Index: patches/patch-xpdf_XPDFCore_cc
===
RCS file: /cvs/ports/textproc/xpdf/patches/patch-xpdf_XPDFCore_cc,v
retrieving revision 1.4
diff -u -p -r1.4 patch-xpdf_XPDFCore_cc
--- patches/patch-xpdf_XPDFCore_cc 30 Mar 2007 04:09:42 - 1.4
+++ patches/patch-xpdf_XPDFCore_cc 24 Apr 2008 15:09:48 -
@@ -1,7 +1,22 @@
$OpenBSD: patch-xpdf_XPDFCore_cc,v 1.4 2007/03/30 04:09:42 ckuethe Exp $
xpdf/XPDFCore.cc.orig Tue Feb 27 22:05:52 2007
-+++ xpdf/XPDFCore.cc Fri Mar 30 00:31:19 2007
-@@ -407,9 +407,6 @@ void XPDFCore::copySelection() {
+--- xpdf/XPDFCore.cc.orig Tue Feb 27 17:05:52 2007
xpdf/XPDFCore.cc Thu Apr 24 11:07:18 2008
+@@ -383,13 +383,8 @@ void XPDFCore::endSelection(int wx, int wy) {
+ }
+ #ifndef NO_TEXT_SELECT
+ if (selectULX != selectLRX
+-selectULY != selectLRY) {
+- if (doc-okToCopy()) {
++selectULY != selectLRY)
+ copySelection();
+- } else {
+-error(-1, Copying of text from this document is not allowed.);
+- }
+- }
+ #endif
+ }
+ }
+@@ -407,9 +402,6 @@ void XPDFCore::copySelection() {
int pg;
double ulx, uly, lrx, lry;
Re: DRM in xpdf
On Thu, Apr 24, 2008 at 3:42 PM, Deanna Phillips [EMAIL PROTECTED] wrote: There's some DRM code left in xpdf that prevents me from copying text. This kills it. ok? Please, don't add things like this to the ports tree. It's purpose is to easy installation, no to add customized programs. And a flavor wouldn't count, as a flavor is a customized _compiled_ program, not a program + third party patches. It even makes harder to see what patches are _needed_ to make the program install.
Re: DRM in xpdf
On Thu, 24 Apr 2008, Deanna Phillips wrote: There's some DRM code left in xpdf that prevents me from copying text. This kills it. ok? [snip] There are similar checks to prevent printing for example. You only need to put return 1; in OkToPrint()[1]. It's trivial to change the source and recompile if you need to. The reason those checks are in there are simple: You need to implement these functions to comply to the PDF specs. I've only needed a patched version of xpdf once to print some crippled PDF. DRM is stupid, especially when you have the source. But I managed by not using crippled PDF documents. Floor [1] I did not check the actual function name. -- Floor Terra [EMAIL PROTECTED] www: http://brobding.mine.nu/
Re: DRM in xpdf
On Thursday 24 April 2008 18:41:44 Andrés wrote: On Thu, Apr 24, 2008 at 3:42 PM, Deanna Phillips [EMAIL PROTECTED] wrote: There's some DRM code left in xpdf that prevents me from copying text. This kills it. ok? Please, don't add things like this to the ports tree. It's purpose is to easy installation, no to add customized programs. And a flavor wouldn't count, as a flavor is a customized _compiled_ program, not a program + third party patches. It even makes harder to see what patches are _needed_ to make the program install. You're completely and utterly wrong. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: DRM in xpdf
I'd support the removal of DRM in xpdf, it's mostly a nuisance then a feature... several programming datasheets have it enabled, it's really rather stupid to prevent user from coping the sample code blocks into a text editor. Please remove stuff like that, it benefits no-one except those loonies over in the US of A. (Apologies if this hits @misc, I'm used to torching them.) -Nix Fan.
Re: DRM in xpdf
On Thu, Apr 24, 2008 at 8:33 PM, Stuart Henderson [EMAIL PROTECTED] wrote: On 2008/04/24 19:41, Andrés wrote: Please, don't add things like this to the ports tree. It's purpose is to easy installation, no to add customized programs. And a flavor wouldn't count, as a flavor is a customized _compiled_ program, not a program + third party patches. It even makes harder to see what patches are _needed_ to make the program install. Shall we also remove the other customizations that fix security problems then? Don't compare security/stability _fixes_ with this...
Re: DRM in xpdf
On Thu, Apr 24, 2008 at 7:58 PM, Brad [EMAIL PROTECTED] wrote: On Thursday 24 April 2008 18:41:44 Andrés wrote: On Thu, Apr 24, 2008 at 3:42 PM, Deanna Phillips [EMAIL PROTECTED] wrote: There's some DRM code left in xpdf that prevents me from copying text. This kills it. ok? Please, don't add things like this to the ports tree. It's purpose is to easy installation, no to add customized programs. And a flavor wouldn't count, as a flavor is a customized _compiled_ program, not a program + third party patches. It even makes harder to see what patches are _needed_ to make the program install. You're completely and utterly wrong. Why?
Re: DRM in xpdf
* Andr?s [EMAIL PROTECTED] [080424 19:55]: On Thu, Apr 24, 2008 at 8:33 PM, Stuart Henderson [EMAIL PROTECTED] wrote: On 2008/04/24 19:41, Andr?s wrote: Please, don't add things like this to the ports tree. It's purpose is to easy installation, no to add customized programs. And a flavor wouldn't count, as a flavor is a customized _compiled_ program, not a program + third party patches. It even makes harder to see what patches are _needed_ to make the program install. Shall we also remove the other customizations that fix security problems then? Don't compare security/stability _fixes_ with this... Take a look at the dwm patches. My personal config is in there... Not taking sides here, just pointing out another data point. Jim
Re: DRM in xpdf
On Thu, Apr 24, 2008 at 4:46 PM, Andrés [EMAIL PROTECTED] wrote: Why? Because ports is about getting things done, and code that gets in the way of you getting things done must die. -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: DRM in xpdf
On Thu, Apr 24, 2008 at 9:05 PM, Chris Kuethe [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 4:46 PM, Andrés [EMAIL PROTECTED] wrote: Why? Because ports is about getting things done, and code that gets in the way of you getting things done must die. Apply your patches locally, fork it, whatever; just don't make the port tree a place to get your favorite patches in. It is for _installing_ stuff.
Re: DRM in xpdf
On Thursday 24 April 2008 19:46:04 Andrés wrote: On Thu, Apr 24, 2008 at 7:58 PM, Brad [EMAIL PROTECTED] wrote: On Thursday 24 April 2008 18:41:44 Andrés wrote: On Thu, Apr 24, 2008 at 3:42 PM, Deanna Phillips [EMAIL PROTECTED] wrote: There's some DRM code left in xpdf that prevents me from copying text. This kills it. ok? Please, don't add things like this to the ports tree. It's purpose is to easy installation, no to add customized programs. And a flavor wouldn't count, as a flavor is a customized _compiled_ program, not a program + third party patches. It even makes harder to see what patches are _needed_ to make the program install. You're completely and utterly wrong. Why? Because what you said is an assumption and is wrong. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: DRM in xpdf
On Thu, Apr 24, 2008 at 5:21 PM, Andrés [EMAIL PROTECTED] wrote: Apply your patches locally, fork it, whatever; just don't make the port tree a place to get your favorite patches in.It is for _installing_ stuff. 1) Too late. We already have some extra patches for various ports because they somehow improve our workflow. 2) You're outvoted. Looks like at least brad@, cloder@, deanna@ and I like the idea of removing code that gets in the way. 3) Don't like the way the OpenBSD ports tree works? Take your own advice and fork it. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: DRM in xpdf
On Thursday 24 April 2008 20:21:30 Andrés wrote: On Thu, Apr 24, 2008 at 9:05 PM, Chris Kuethe [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 4:46 PM, Andrés [EMAIL PROTECTED] wrote: Why? Because ports is about getting things done, and code that gets in the way of you getting things done must die. Apply your patches locally, fork it, whatever; just don't make the port tree a place to get your favorite patches in. It is for _installing_ stuff. No, it is for installing software which allows me to get things done. It has nothing to do with favorite patches. I had already ripped out this DRM bullshit 4.5 years ago thanks to cloder@ for pointing this out by sending diffs. It seems another check was added along the way when upgrading to newer versions. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: DRM in xpdf
On Fri, 24 Apr 2008, Unix Fan wrote: I'd support the removal of DRM in xpdf, it's mostly a nuisance then a feature... One could even classify it as a security problem (on PDF protocol level), since the user of a PDF document is vulnerable to a denial-of-service attack from a mischevious author. (The services to copy and/or print a particular text can be denied without the user's consent.) Just in case someone thinks that patches should be restricted to security fixes... And since the xpdf author doesn't agree that DRM is a stupid thing to enforce (see http://www.foolabs.com/xpdf/cracking.html) it seems hard to remove it by an upstream patch. /Johan
Re: DRM in xpdf
On Thu, Apr 24, 2008 at 9:05 PM, Chris Kuethe [EMAIL PROTECTED] wrot= e: On Thu, Apr 24, 2008 at 4:46 PM, Andr=E9s [EMAIL PROTECTED] wrote: Why? Because ports is about getting things done, and code that gets in the way of you getting things done must die. Apply your patches locally, fork it, whatever; just don't make the port tree a place to get your favorite patches in. It is for _installing_ stuff. Thank you very much for your opinion, but it is clear you come with an agenda. The OpenBSD project people do not follow the bend to Adobe agenda that some xpdf people follow. Bye bye.
