Licensing Issues for LC developers [was: Re: Reading PDF - a cry for help]
Bernard Devlin wrote (see his whole message at the end of this email): You're either extremely knowledgeable about the GPL, or I think you have misunderstood the GPL. The first is certainly not true, so the second is more than likely. I got my (hopefully wrong!) information from the site of Artifex, who maintain and sell the commercial version of Ghostscript and its derivatives. They say: If your application (including its source code) is not licensed to the public under the GNU GPL, you are not authorized to ship GPL Ghostscript or GPL MuPDF with your application under the terms of the GNU GPL if any one of the following is true: your application contains a copy of some or all of GPL Ghostscript or MuPDF; your application is derived from, is based on, or constitutes a revision of some or all of GPL Ghostscript or MuPDF; your application includes one or more functions that use some or all of GPL Ghostscript or MuPDF. These criteria apply to your application as a whole. Even if only one section of your application satisfies one of these criteria, you are not authorized to ship GPL Ghostscript or GPL MuPDF with your application unless your application, including all of its source code, is licensed to the public under the GNU GPL. If your application (including its source code) is NOT licensed to the public under the GNU GPL and you intend to distribute Ghostscript or MuPDF to a third party for use with and usable by your application, you MUST first obtain a commercial license from Artifex. I perhaps naively believed all this without further research. I have now read the GPL - it is quite tough to follow, but I tried to test it on what I actually want to do, which is to distribute Ghostscript or an existing derivative of it unaltered along with my own application (written in LiveCode, a proprietary software system) and for sale as a product under 'normal' commercial terms. In the Preamble, the GPL states: For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. The applicable part of the GPL referring to compiled and complete versions of programs (such as GhostScript in binary form, which is what I intend to use) is Section 6. It does allow use of the compiled code, provided that the user is offered access to the source code (this is 6b). So Bernard, I think you are right and that Artifex is wrong - which means the use of 'free' software (using the term as GNU uses it) is OK. Thanks Bernard for that very interesting insight. Graham PS I will return to the technical argument (which seems to be getting rather tetchy) about the use of IM, GhostScript etc. soon. I thought it better to keep the licensing discussion separate. On Sat, 1 Oct 2011 15:40:57 +0100, Bernard Devlin bdrun...@gmail.com wrote: You're either extremely knowledgeable about the GPL, or I think you have misunderstood the GPL. The GPL v2 does not mean you cannot charge for re-distribution of GPL code (there are companies who charge for the re-distribution of linux on dvds). If your code is bound to GPL libraries and you distribute that combined artifact then you might have issues. If your code calls out to compiled programs (using shell() then there is no issue). A very strict interpretation is that if your code is bound to libraries, then you are bound to provide your souce should someone demand it, or cease using the libraries in that case. There are those who dispute that even binding to libraries does not fall within the GPL v2. GPL v3 was brought in to stop so many companies exploiting GPL on the server-side (i.e. where there is no re-distribution of code). Unless the code you want to use to provide such a web service is licensed under GPL v3, I cannot see what the issue would be. I know of very few projects using GPL v3. And not all open source licenses have the same copyleft implications as the GPL. If you are distributing RunRev's ssl library with your apps, you are re-distributing open source code (only this time it is the Apache license + SSL license). It is always possible that companies negotiate a separate non-GPL license for GPL code they wish to incorporate and re-distribute. Anyway, I hope the first suggestion works for you so that you do not even need to consider these issues. Bernard On Sat, Oct 1, 2011 at 1:22 PM, Graham Samuel livf...@mac.com wrote: since mine is a commercial product, there would presumably be licensing issues for a non-GNU developer. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
Re: Licensing Issues for LC developers [was: Re: Reading PDF - a cry for help]
FYI: The work around that I have seen used is to keep your code and the GPL code completely separate. In fact, when someone downloads and installs your code, the very first thing your code would do is ask people to approve the install of the GPL code. Then if they say yes, download the binary and install it on their computer. If they say no, let them know your software cannot function without the GPL code and then offer them the option of getting a refund or having your code download the GPL binary.. Thus, you ship just your code. They purchase just your code. Your code installs the free GPL code if the user asks for it to be installed. In your manual or help screens you provide links to the source of the GPL code. That process seems to be used by others. Of course, I am not a lawyer and I don't even play one on TV so you should assume everything I have just written is incorrect. Kee Nethery On Oct 3, 2011, at 4:03 AM, Graham Samuel wrote: The applicable part of the GPL referring to compiled and complete versions of programs (such as GhostScript in binary form, which is what I intend to use) is Section 6. It does allow use of the compiled code, provided that the user is offered access to the source code (this is 6b). So Bernard, I think you are right and that Artifex is wrong - which means the use of 'free' software (using the term as GNU uses it) is OK. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Licensing Issues for LC developers [was: Re: Reading PDF - a cry for help]
My pleasure. I'm sure that there are plenty of discussions on the internet that will help you further understand what is possible and where the limitations are. It seems a shame to throw away a possible solution to a problem on a misunderstanding of the possibilities. My thoughts on the matter were based on my recollection of discussions with Richard years ago. I don't actually distribute any GPL software with my applications, so the possibilities and limitations are mostly of academic interest to me. Like Kee, I'm not a lawyer. I hope the suggestions on the other thread provide you with technical feasibilities. Let us know if your research uncovers issues that we laymen have missed. When I've tried to discuss the GPL with lawyer friends, they are very reluctant to give me a firm opinion of what is involved (it makes me wonder if they are really worth the social liability entailed in having them as friends). Bernard On Mon, Oct 3, 2011 at 12:03 PM, Graham Samuel livf...@mac.com wrote: Thanks Bernard for that very interesting insight. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Thanks Roger, that's really interesting. As I can't operate under a GNU license, I believe I would have to pay Artifex to use Ghostscript or MuPDF (which is probably good enough for my rather modest functional requirement). I have emailed Artifex about their licensing terms and I imagine they'll reply next week. If as I fear they want a per-copy fee, I couldn't live with that since my app is very price sensitive (UK schools don't have much money). We'll see. Graham On 30 Sep 2011, Roger Eller roger.e.el...@sealedair.com wrote: 1 On Fri, Sep 30, 2011 at 11:02 AM, Graham Samuel wrote: Thanks to all who replied. As the one who started this thread, I'd like to say that I pretty much despair of finding a solution. The current position seems to me admirably summarised by Paul Dupuis (see below). Suggestions that I use a command-line utility seem to me to come down to using ImageMagick since I have not found any other solution that has the right functionality and licensing terms Graham I posted this little GhostScript function to go from PDF to JPEG in January of 2011 in a similar thread. It is command-line based, but the overhead is less than that of Image Magic, I think. http://www.mail-archive.com/use-livecode@lists.runrev.com/msg03282.html ~Roger ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Thanks Bernard. I will look into (1), although I have no idea of the resource implications, but for (2) I don't think my publisher would consider a solution involving the permanent involvement of an external server, plus the fact that I know nothing about Linux, plus the fact that the owner of the PDF (usually a UK government agency or licensee) might consider transfer to an external server to be a violation of its terms of use, plus the fact that since mine is a commercial product, there would presumably be licensing issues for a non-GNU developer. But an interesting thought. Graham On 30 Sep 2011, at 19:08:31 +0100, Bernard Devlin bdrun...@gmail.com wrote: I have a couple of suggestions (although I am not sure either will work as smoothly as Graham wants, but my still be worth a try). 1. display the pdf in a browser control, snapshot the window, present the snapshot to the user to crop to just the image. 2. assuming that there is a linux solution (I've used pdf2txt or some such on Linux to extract the text out of 1000 page pdf files), create your own webservice that will accept a PDF file and a page number, and it returns an image of the page to be cropped by the user. I have created such a web service before which took files in various office formats and returned the data from the files (using OpenOffice running headless on the linux server to extract the text). Whilst such a service might seem like a lot of work to setup, it is going to be easier than writing an external or (I would imagine) parsing PostScript (although I do have the PostScript manuals and specification lying around here somewhere in PDF format). You can get your own VPS at Linode for approx $20 a month. Bernard ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
You're either extremely knowledgeable about the GPL, or I think you have misunderstood the GPL. The GPL v2 does not mean you cannot charge for re-distribution of GPL code (there are companies who charge for the re-distribution of linux on dvds). If your code is bound to GPL libraries and you distribute that combined artifact then you might have issues. If your code calls out to compiled programs (using shell() then there is no issue). A very strict interpretation is that if your code is bound to libraries, then you are bound to provide your souce should someone demand it, or cease using the libraries in that case. There are those who dispute that even binding to libraries does not fall within the GPL v2. GPL v3 was brought in to stop so many companies exploiting GPL on the server-side (i.e. where there is no re-distribution of code). Unless the code you want to use to provide such a web service is licensed under GPL v3, I cannot see what the issue would be. I know of very few projects using GPL v3. And not all open source licenses have the same copyleft implications as the GPL. If you are distributing RunRev's ssl library with your apps, you are re-distributing open source code (only this time it is the Apache license + SSL license). It is always possible that companies negotiate a separate non-GPL license for GPL code they wish to incorporate and re-distribute. Anyway, I hope the first suggestion works for you so that you do not even need to consider these issues. Bernard On Sat, Oct 1, 2011 at 1:22 PM, Graham Samuel livf...@mac.com wrote: since mine is a commercial product, there would presumably be licensing issues for a non-GNU developer. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: Reading PDF - a cry for help
I have had some success parsing PDF files for various purposes using the shell command to access tools like pdftk, ghostpdl/ghostscript and the xpdf suite of command line tools. Walt Brown -Original Message- snip ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: Reading PDF - a cry for help
The problem (success?) with pdf is that it is, uniquely, pdf: it is text, stylized text, bitmaps, vector graphics, and everything else. Covert eps, for example, to pdf and all is fine (you can easily extract the eps from the pdf). Add a second pdf (or another eps) to that same file, and the eps becomes encoded pdf: the same is true for stylized text or anything else. All of which is to say, you cannot easily extract a precise image from a more complex pdf file, especially one that is vector graphics in form. You can, as Preview does, cut from a pdf an aspect of that pdf as a pdf image, but that pdf won't be the original graphic (typically). You can also extract the text in a simple ascii form that, typically on Windows, loses all the ligatures (on the Mac it is usually more successful). TeXShop, unlike Preview, for example, does try to extract eps from pdf, but fails if the encoding was other than eps--pdf. Preview just doesn't bother as it is not usually possible. OTH, pdf--pdf always works, which is one of the principle reasons pdf dominates everywhere (except in that dark world of Windows). I do most of my work in LaTeX, and most of my figures are vector graphics. That means an entire manuscript when compiled to pdf, including all the stylized text, tables and figures is *at most* a few hundred K. I have books I have written in LaTeX that over hundreds of pages and figures are still at most a few megabytes when compiled to pdf. Even one of those figures of those documents if converted from pdf to say, png, or tiff, or jpeg would be larger than the entire document in pdf. My point is simple: if in pdf stay there: it is already the best format. On 2011-09-29, at 6:56 PM, use-livecode-requ...@lists.runrev.com wrote: I find all of this somewhat tantalizing, but the only way I've found to make a PDF document useful in what I'm doing is to take a screen shot of it and then paste or import it as an image into the other application. Though I do this mostly in MacDraft, I should imagine that the same technique can be used in LC, since I often use MD as a method of transitioning different kinds of images into LC. Of course I'm interested in what you see in a PDF; not what else there might be there, of which I know nothing. I don't understand all of this parsing of data from or in a PDF. Joe Wilkins -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -Dr. John R. Vokey ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: Reading PDF - a cry for help
I like that. pdf works everywhere (except that dark corner of windows) - oh, you mean the 98% of all computer users dark corner? Oops, forgot about them. Mike On Fri, 30 Sep 2011 01:12:43 -0600, Vokey, John wrote: The problem (success?) with pdf is that it is, uniquely, pdf: it is text, stylized text, bitmaps, vector graphics, and everything else. Covert eps, for example, to pdf and all is fine (you can easily extract the eps from the pdf). Add a second pdf (or another eps) to that same file, and the eps becomes encoded pdf: the same is true for stylized text or anything else. All of which is to say, you cannot easily extract a precise image from a more complex pdf file, especially one that is vector graphics in form. You can, as Preview does, cut from a pdf an aspect of that pdf as a pdf image, but that pdf won't be the original graphic (typically). You can also extract the text in a simple ascii form that, typically on Windows, loses all the ligatures (on the Mac it is usually more successful). TeXShop, unlike Preview, for example, does try to extract eps from pdf, but fails if the encoding was other than eps--pdf. Preview just doesn't bother as it is not usually possible. OTH, pdf--pdf always works, which is one of the principle reasons pdf dominates everywhere (except in that dark world of Windows). I do most of my work in LaTeX, and most of my figures are vector graphics. That means an entire manuscript when compiled to pdf, including all the stylized text, tables and figures is *at most* a few hundred K. I have books I have written in LaTeX that over hundreds of pages and figures are still at most a few megabytes when compiled to pdf. Even one of those figures of those documents if converted from pdf to say, png, or tiff, or jpeg would be larger than the entire document in pdf. My point is simple: if in pdf stay there: it is already the best format. On 2011-09-29, at 6:56 PM, use-livecode-requ...@lists.runrev.com [1]wrote: I find all of this somewhat tantalizing, but the only way I've found to make a PDF document useful in what I'm doing is to take a screen shot of it and then paste or import it as an image into the other application. Though I do this mostly in MacDraft, I should imagine that the same technique can be used in LC, since I often use MD as a method of transitioning different kinds of images into LC. Of course I'm interested in what you see in a PDF; not what else there might be there, of which I know nothing. I don't understand all of this parsing of data from or in a PDF. Joe Wilkins -- Please avoid sending me Word or PowerPoint attachments. See -Dr. John R. Vokey ___ use-livecode mailing list use-livecode@lists.runrev.com [3] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode [4] Links: -- [1] mailto:use-livecode-requ...@lists.runrev.com [2] http://www.gnu.org/philosophy/no-word-attachments.html [3] mailto:use-livecode@lists.runrev.com [4] http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
On 09/30/2011 04:21 PM, Admin wrote: I like that. pdf works everywhere (except that dark corner of windows) - oh, you mean the 98% of all computer users dark corner? Oops, forgot about them. Mike As our house is completely non-Windows [mixed Mac, Ubuntu-Linux, Mint-Linux], and my wife has to print out her handouts at the University of Plovdiv [100% Windows]; as most of her stuff contains an Anglo-Saxon-cum-Middle-English font made by me, she is ALWAYS very careful to pump out her finished work as PDF files, stick them on the flash drive, and wander up the road to the Uni' . . . . . . Safe in the knowledge that PDF is the ONLY format that works cross-platform [i.e. Mac + Windows + Linux] every single time. So remarks about dark corners don't really make much sense. Certainly, the installs of Windows XP at the University of Plovdiv have no problem at all printing out whatever we can throw at them from our alien operating systems. I do know that Adobe's PDF reader does not always sit prettily with Windows, and I tend to install Foxit for my friends: http://www.foxitsoftware.com/Secure_PDF_Reader/ I don't like Windows, but the fact is that hereabouts (at least) 99% of the place uses Windows, and, on the whole, seem to manage remarkably well. The fact that I don't like Windows has not stopped me installing it and tweaking it for people who would prefer it to other operating systems; the only thing they have had to put up with is a 20 minute anti-Windows rant from me first . . . :) Actually fairly cheap as the going rate for a windows install round here (I mean the act of installing, not the licence) is currently running at about 50 Euros). My main grump about Windows boils down to 3 things: 1. I can run Pentium 2,3 4 machines much faster and more efficiently on types of Linux than on Windows 98 and XP. 2. Kids who turn up with written work on Flash drives from there home systems are not going to virus my machines and ruin my weekend by having to reinstall everything for the 95th time. 3. I'd rather spend my money on things I see as more directly relevant to my work, such as specialist learner keyboards, educational DVDs and so forth, than a plain bread-and-butter OS to underpin the work. I used to be anti-PDF because it is not Open Source; but then, Hey, nor is Livecode. And Open Source (sorry, Shri Shri Richard Stallman) is NOT a virtue in and of itself; and, having gone to a talk by R. Stallman, I got turned off his shrill, one-sided, rather bigotted rantings. And, however much I like Open Source, I cannot see a viable alternative to PDF right now. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Thanks to all who replied. As the one who started this thread, I'd like to say
that I pretty much despair of finding a solution. The current position seems to
me admirably summarised by Paul Dupuis (see below). Suggestions that I use a
command-line utility seem to me to come down to using ImageMagick since I have
not found any other solution that has the right functionality and licensing
terms - but when I looked into it, although I freely admit I know almost
nothing about the internal workings of Windows, it seemed to me that IM is a
resources hog that would not be amenable to a simple installation process
hidden from the user; and that operating it so as to provide a LiveCode window
containing the relevant representation would not be straightforward and would
certainly mean clunky intermediate files. So it would be very very different
from an 'import paint' situation. Bear in mind that I am not interested in the
text in a PDF, just the image content (just a bitmap really), so things like IM
are overkill for me anyway. But this 'modest' requirement hasn't got me any
nearer a solution.
What really annoys me is that if I were writing my app in Visual Basic, I
suspect there would be library components available with the right licensing
terms, but the promise of a simple 'glue' or 'wrapper' capability to tie
LiveCode to third-party externals whose APIs were not written with LiveCode in
mind has not been fulfilled, even though it has been proposed in some versions
of the LC documentation.
Before I completely give up I will go round the ImageMagick route once more,
since I suppose I may have misunderstood its resource requirements, and it does
have the advantage of being able to read TIFFs, which is another problem I have
(also not likely to be on LiveCode's radar despite QA requests).
As a last remark, I'd be interested to know of the details of ANY
implementation of adding functionality of any kind to LiveCode via a
third-party application and 'shell'. I have never seen this in action and I
can't remember it being demonstrated by anyone on this list - but maybe I just
wasn't paying attention.
Graham
On 9/29/2011 10:01 AM, Graham Samuel wrote:
Short of RunRev itself extending input formats to include PDF (not impossible,
but not likely in the short term), the solution would seem to be to licence a
third-party library component and integrate it into my app by the use of
bridging ('glue') code. I got pretty near with this one, having identified a
component with suitable licensing terms and functionality (Sorax DLL). RunRev
suggested that I could do the gluing with the aid of a 'C' programmer. It turns
out after a lot of research by Thierry Douez, who has been helping me, that
what I need is a person familiar with Visual Studio to accomplish this - but I
despair of finding such a person who would also be familiar with the externals
interface of the LiveCode engine. Maybe I will find such a person, but the
trail does seem to have gone cold.
Has anyone any suggestion as to how I might proceed? My app works so nicely
with JPG and PNG files, and I have (a little) belief that I could make it work
with TIFF files, but without PDF input I am dead in the water.
As some folks may remember, I have posted to this list a number of time
on the need for being able to open and read PDF content (text and
images) in LiveCode. We at Researchware have, I think, thoroughly
explored this topic. It all boils down to the fact you need 3rd party
technology that can read the PDF format and render it and/or extract the
text from it.
For pages as images or unstylized text, the cheap and dirty way is to
use a 3rd party command-line utility to make your conversions. From a
script perspective, you perform an answer file command, get the PDF
file, and then use shell to batch convert it and then read the resulting
text file or image file(s) back in. There is NO other free way to do
this. Yes, this is ugly and probably not for the novice scripter and you
code pretty much has to be platform specific, but again, it is the ONLY
free way to do this. You are also not every displaying a real PDF - you
are either displaying images of pages OR the unformatted, unstyled text.
You can also do a limited form of displaying a PDF in a window (you
can't get or copy any selections/content in it though and can only
navigate under script control by page) through InterApplication
communication (IAC)
To open a PDF in LiveCode where you can actually control navigation
through script control and get or set the user selections required two
things: (a) a PDF library with APIs supporting these actions and (b)
creating a set of LiveCode externals that in turn use the PDF APIs to
provide these functions. The main problem with this approach is that all
(or all we could find) of the open source or free PDF libraries are
woefully immature and lack major functionality. Only commercial PDF
technology
Re: Reading PDF - a cry for help
Paul- Thursday, September 29, 2011, 10:55:35 AM, you wrote: As some folks may remember, I have posted to this list a number of time on the need for being able to open and read PDF content (text and images) in LiveCode. We at Researchware have, I think, thoroughly explored this topic. It all boils down to the fact you need 3rd party technology that can read the PDF format and render it and/or extract the text from it. IIRC you were looking not just to extract the content but to keep the page formatting, and that requires not just extracting the binary content (easy enough to do) but extracting all the page layout commands and executing them in your own interpreter. That's a bit more of a task. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
On 30 Sep 2011, at 17:02, Graham Samuel wrote: As a last remark, I'd be interested to know of the details of ANY implementation of adding functionality of any kind to LiveCode via a third-party application and 'shell'. I have never seen this in action and I can't remember it being demonstrated by anyone on this list - but maybe I just wasn't paying attention. Mark made a presentation about extending livecode: http://livecode.tv/2011/06/live-livecode-code-event-26-wrapup/ Mark Schonewille will introduce you to extending LiveCode when LiveCode can’t do it alone. He will explore the possibilities of “shell”, “open process”, “do as” and “launch program”. -- Watch live presentations every Saturday: http://livecode.tv Use an alternative Dictionary viewer: http://bjoernke.com/bvgdocu/ Chat with other RunRev developers: http://bjoernke.com/chatrev/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
I have a couple of suggestions (although I am not sure either will work as smoothly as Graham wants, but my still be worth a try). 1. display the pdf in a browser control, snapshot the window, present the snapshot to the user to crop to just the image. 2. assuming that there is a linux solution (I've used pdf2txt or some such on Linux to extract the text out of 1000 page pdf files), create your own webservice that will accept a PDF file and a page number, and it returns an image of the page to be cropped by the user. I have created such a web service before which took files in various office formats and returned the data from the files (using OpenOffice running headless on the linux server to extract the text). Whilst such a service might seem like a lot of work to setup, it is going to be easier than writing an external or (I would imagine) parsing PostScript (although I do have the PostScript manuals and specification lying around here somewhere in PDF format). You can get your own VPS at Linode for approx $20 a month. Bernard ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
On Fri, Sep 30, 2011 at 11:02 AM, Graham Samuel wrote: Thanks to all who replied. As the one who started this thread, I'd like to say that I pretty much despair of finding a solution. The current position seems to me admirably summarised by Paul Dupuis (see below). Suggestions that I use a command-line utility seem to me to come down to using ImageMagick since I have not found any other solution that has the right functionality and licensing terms Graham I posted this little GhostScript function to go from PDF to JPEG in January of 2011 in a similar thread. It is command-line based, but the overhead is less than that of Image Magic, I think. http://www.mail-archive.com/use-livecode@lists.runrev.com/msg03282.html ~Roger ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Reading PDF - a cry for help
Folks, for some months now (it seems even longer) I have been seeking a
solution to the problem of reading PDF-formatted images into Livecode stacks.
What I'm looking for is solution that looks like an 'import paint' command: in
other words, I want to be able to load a small subset of the possible contents
of a PDF - just bitmap images - into a stack via script. Sadly I want to do
this on a PC, running at a minimum Windows XP. My users want a simple solution
that makes reading from a PDF no more complicated than reading a JPG.
I have explored several possibilities, including using a 'free' PDF reader that
is somehow hidden from the user of my app, and using say 'shell' to control it
and to pass an image to LiveCode. However I have not found a realistic way of
doing this, particularly when I include the need to have a very simple
installation process - the user should not see any additional application, nor
be obliged to provide substantial additional resources, as would be true for
example if one used ImageMagick in this way in a PC context.
Short of RunRev itself extending input formats to include PDF (not impossible,
but not likely in the short term), the solution would seem to be to licence a
third-party library component and integrate it into my app by the use of
bridging ('glue') code. I got pretty near with this one, having identified a
component with suitable licensing terms and functionality (Sorax DLL). RunRev
suggested that I could do the gluing with the aid of a 'C' programmer. It turns
out after a lot of research by Thierry Douez, who has been helping me, that
what I need is a person familiar with Visual Studio to accomplish this - but I
despair of finding such a person who would also be familiar with the externals
interface of the LiveCode engine. Maybe I will find such a person, but the
trail does seem to have gone cold.
Has anyone any suggestion as to how I might proceed? My app works so nicely
with JPG and PNG files, and I have (a little) belief that I could make it work
with TIFF files, but without PDF input I am dead in the water.
TIA
Graham
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Graham, Your best bet: http://qery.us/136 -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 See what you get with only a small contribution. All our LiveCode downloads are listed at http://qery.us/zr On 29 sep 2011, at 16:01, Graham Samuel wrote: Folks, for some months now (it seems even longer) I have been seeking a solution to the problem of reading PDF-formatted images into Livecode stacks. What I'm looking for is solution that looks like an 'import paint' command: in other words, I want to be able to load a small subset of the possible contents of a PDF - just bitmap images - into a stack via script. Sadly I want to do this on a PC, running at a minimum Windows XP. My users want a simple solution that makes reading from a PDF no more complicated than reading a JPG. snip ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Well. . . I just set up a new stack (on Linux!) and imported a PDF as a
text file, and ended up
with a text field of gobbledegook . . .
BUT, at least the ting imports PDF files; ALL (!!!) one has to do
then . . . [rather you than me, mate] . . . is knock together a set of
algorhythms to convert the PDF file into readable text, strip out
control chars, read formatting signs, and so on.
This is probably total crap; just a thought based on the realisation
that Livecode can import any file as TEXT.
On 09/29/2011 05:01 PM, Graham Samuel wrote:
Folks, for some months now (it seems even longer) I have been seeking a
solution to the problem of reading PDF-formatted images into Livecode stacks.
What I'm looking for is solution that looks like an 'import paint' command: in
other words, I want to be able to load a small subset of the possible contents
of a PDF - just bitmap images - into a stack via script. Sadly I want to do
this on a PC, running at a minimum Windows XP. My users want a simple solution
that makes reading from a PDF no more complicated than reading a JPG.
I have explored several possibilities, including using a 'free' PDF reader that
is somehow hidden from the user of my app, and using say 'shell' to control it
and to pass an image to LiveCode. However I have not found a realistic way of
doing this, particularly when I include the need to have a very simple
installation process - the user should not see any additional application, nor
be obliged to provide substantial additional resources, as would be true for
example if one used ImageMagick in this way in a PC context.
Short of RunRev itself extending input formats to include PDF (not impossible,
but not likely in the short term), the solution would seem to be to licence a
third-party library component and integrate it into my app by the use of
bridging ('glue') code. I got pretty near with this one, having identified a
component with suitable licensing terms and functionality (Sorax DLL). RunRev
suggested that I could do the gluing with the aid of a 'C' programmer. It turns
out after a lot of research by Thierry Douez, who has been helping me, that
what I need is a person familiar with Visual Studio to accomplish this - but I
despair of finding such a person who would also be familiar with the externals
interface of the LiveCode engine. Maybe I will find such a person, but the
trail does seem to have gone cold.
Has anyone any suggestion as to how I might proceed? My app works so nicely
with JPG and PNG files, and I have (a little) belief that I could make it work
with TIFF files, but without PDF input I am dead in the water.
TIA
Graham
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Has anyone any suggestion as to how I might proceed? My app works so nicely with JPG and PNG files, and I have (a little) belief that I could make it work with TIFF files, but without PDF input I am dead in the water. Graham, the other alternative is to work with the PDF file on a binary level (I'm working on something like that right now for importing PSD files). After a quick glance at the PDF specification it looks like a bunch of it is in plain text so it might actually be easier to work with it that way. Are you looking at just extracting the images? Or other relevant parts of the PDF? The reason I ask is that it looks like binary data is always contained between two lines: stream and endstream, so extracting just the streaming data should be pretty quick to do; although the next step would be going to read the bytes of what was extracted and then determine if it's an image or some other thing that had to be represented with a stream in the PDF... Just my 2 cents, Ken Ray Sons of Thunder Software, Inc. Email: k...@sonsothunder.com Web Site: http://www.sonsothunder.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
I see three directions to pulling images out of PDF files on Windows:
1. Use a command-line utility and shell() plus file I/O
2. Loosely parse the PDF file
3. Create an external
I recommend starting with #1 and seeing how it works for you. All are
possible.
Dar
On Sep 29, 2011, at 8:01 AM, Graham Samuel wrote:
Folks, for some months now (it seems even longer) I have been seeking a
solution to the problem of reading PDF-formatted images into Livecode stacks.
What I'm looking for is solution that looks like an 'import paint' command:
in other words, I want to be able to load a small subset of the possible
contents of a PDF - just bitmap images - into a stack via script. Sadly I
want to do this on a PC, running at a minimum Windows XP. My users want a
simple solution that makes reading from a PDF no more complicated than
reading a JPG.
I have explored several possibilities, including using a 'free' PDF reader
that is somehow hidden from the user of my app, and using say 'shell' to
control it and to pass an image to LiveCode. However I have not found a
realistic way of doing this, particularly when I include the need to have a
very simple installation process - the user should not see any additional
application, nor be obliged to provide substantial additional resources, as
would be true for example if one used ImageMagick in this way in a PC context.
Short of RunRev itself extending input formats to include PDF (not
impossible, but not likely in the short term), the solution would seem to be
to licence a third-party library component and integrate it into my app by
the use of bridging ('glue') code. I got pretty near with this one, having
identified a component with suitable licensing terms and functionality (Sorax
DLL). RunRev suggested that I could do the gluing with the aid of a 'C'
programmer. It turns out after a lot of research by Thierry Douez, who has
been helping me, that what I need is a person familiar with Visual Studio to
accomplish this - but I despair of finding such a person who would also be
familiar with the externals interface of the LiveCode engine. Maybe I will
find such a person, but the trail does seem to have gone cold.
Has anyone any suggestion as to how I might proceed? My app works so nicely
with JPG and PNG files, and I have (a little) belief that I could make it
work with TIFF files, but without PDF input I am dead in the water.
TIA
Graham
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
---
Dar Scott
dba
Dar Scott Consulting
8637 Horacio Place NE
Albuquerque, NM 87111
Lab, home, office phone: +1 505 299 9497
For Skype and fax, please contact.
d...@swcp.com
Computer Programming and tinkering,
often making LiveCode libraries and
externals, sometimes writing associated
microcontroller firmware.
---
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
On Sep 29, 2011, at 9:24 AM, Ken Ray wrote: Are you looking at just extracting the images? Or other relevant parts of the PDF? The reason I ask is that it looks like binary data is always contained between two lines: stream and endstream, so extracting just the streaming data should be pretty quick to do; although the next step would be going to read the bytes of what was extracted and then determine if it's an image or some other thing that had to be represented with a stream in the PDF... There are a couple issues that complicate this in general. The parameters needed to process the stream need to be parsed and they can be far away. There are many stream filters (some complicated compression) and they can be nested. I looked at a corpus of PDF files and, yeah, a several are used in practice. However, if one needs to parse the output of a specific program or a specific model of a scanner, then the work to do parsing in LiveCode is a lot less. I hope that makes sense; I'm a little under the weather today. Dar ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
I find all of this somewhat tantalizing, but the only way I've found to make a PDF document useful in what I'm doing is to take a screen shot of it and then paste or import it as an image into the other application. Though I do this mostly in MacDraft, I should imagine that the same technique can be used in LC, since I often use MD as a method of transitioning different kinds of images into LC. Of course I'm interested in what you see in a PDF; not what else there might be there, of which I know nothing. I don't understand all of this parsing of data from or in a PDF. Joe Wilkins On Sep 29, 2011, at 9:50 AM, Dar Scott wrote: On Sep 29, 2011, at 9:24 AM, Ken Ray wrote: Are you looking at just extracting the images? Or other relevant parts of the PDF? The reason I ask is that it looks like binary data is always contained between two lines: stream and endstream, so extracting just the streaming data should be pretty quick to do; although the next step would be going to read the bytes of what was extracted and then determine if it's an image or some other thing that had to be represented with a stream in the PDF... There are a couple issues that complicate this in general. The parameters needed to process the stream need to be parsed and they can be far away. There are many stream filters (some complicated compression) and they can be nested. I looked at a corpus of PDF files and, yeah, a several are used in practice. However, if one needs to parse the output of a specific program or a specific model of a scanner, then the work to do parsing in LiveCode is a lot less. I hope that makes sense; I'm a little under the weather today. Dar ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
There are command-line utilities that will take a pdf page and render it onto an image and store the image as a standard file. Some work with multiple page documents. These can work with the LiveCode shell() function. Dar On Sep 29, 2011, at 11:02 AM, Joe Lewis Wilkins wrote: I find all of this somewhat tantalizing, but the only way I've found to make a PDF document useful in what I'm doing is to take a screen shot of it and then paste or import it as an image into the other application. Though I do this mostly in MacDraft, I should imagine that the same technique can be used in LC, since I often use MD as a method of transitioning different kinds of images into LC. Of course I'm interested in what you see in a PDF; not what else there might be there, of which I know nothing. I don't understand all of this parsing of data from or in a PDF. Joe Wilkins On Sep 29, 2011, at 9:50 AM, Dar Scott wrote: On Sep 29, 2011, at 9:24 AM, Ken Ray wrote: Are you looking at just extracting the images? Or other relevant parts of the PDF? The reason I ask is that it looks like binary data is always contained between two lines: stream and endstream, so extracting just the streaming data should be pretty quick to do; although the next step would be going to read the bytes of what was extracted and then determine if it's an image or some other thing that had to be represented with a stream in the PDF... There are a couple issues that complicate this in general. The parameters needed to process the stream need to be parsed and they can be far away. There are many stream filters (some complicated compression) and they can be nested. I looked at a corpus of PDF files and, yeah, a several are used in practice. However, if one needs to parse the output of a specific program or a specific model of a scanner, then the work to do parsing in LiveCode is a lot less. I hope that makes sense; I'm a little under the weather today. Dar ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode --- Dar Scott dba Dar Scott Consulting 8637 Horacio Place NE Albuquerque, NM 87111 Lab, home, office phone: +1 505 299 9497 For Skype and fax, please contact. d...@swcp.com Computer Programming and tinkering, often making LiveCode libraries and externals, sometimes writing associated microcontroller firmware. --- ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Not sure about your needs but... You can save a lot of time between MacDraft and PDFs by using Blue Mango's wonderful and fully supported Clairfy. Select, copy to PDF in one step with annotations available and online distribution if you want. It's FREE and highly recommended. Get Clarify HERE http://www.bluemangolearning.com/clarify/ If your work includes MacDraft, you should know about the (Autocad standard) DWG/DXF import and export feature. It is all plain text and human readable, with point, line and position data that some of which could be turned into corresponding LC commands. But it might be easier to just use Clarify. It's really good. On 29 September 2011 10:02, Joe Lewis Wilkins pepe...@cox.net wrote: I find all of this somewhat tantalizing, but the only way I've found to make a PDF document useful in what I'm doing is to take a screen shot of it and then paste or import it as an image into the other application. Though I do this mostly in MacDraft, I should imagine that the same technique can be used in LC, since I often use MD as a method of transitioning different kinds of images into LC. Of course I'm interested in what you see in a PDF; not what else there might be there, of which I know nothing. I don't understand all of this parsing of data from or in a PDF. Joe Wilkins On Sep 29, 2011, at 9:50 AM, Dar Scott wrote: On Sep 29, 2011, at 9:24 AM, Ken Ray wrote: Are you looking at just extracting the images? Or other relevant parts of the PDF? The reason I ask is that it looks like binary data is always contained between two lines: stream and endstream, so extracting just the streaming data should be pretty quick to do; although the next step would be going to read the bytes of what was extracted and then determine if it's an image or some other thing that had to be represented with a stream in the PDF... There are a couple issues that complicate this in general. The parameters needed to process the stream need to be parsed and they can be far away. There are many stream filters (some complicated compression) and they can be nested. I looked at a corpus of PDF files and, yeah, a several are used in practice. However, if one needs to parse the output of a specific program or a specific model of a scanner, then the work to do parsing in LiveCode is a lot less. I hope that makes sense; I'm a little under the weather today. Dar ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Stephen Barncard San Francisco Ca. USA more about sqb http://www.google.com/profiles/sbarncar ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: Reading PDF - a cry for help
I've been trying to find a way just to render a PDF in LC on Android and
iOS. There are several major roadblock even after rendering such as links,
bookmarks, buttons, combo boxes, etc. But then there's also the java issue.
Read the PDF specification for a real headache So to implement the PDF
object is not as easy as it might seem. There must be some 3rd party PDF
renders out there that might be able to dovetail into LC. This would allow
distribution of PDF via an app with some modicum of DRM.
Ralph DiMola
IT Director
Evergreen Information Services
Phone: 518-636-3998 Ex:11
Cell: 518-796-9332
-Original Message-
From: use-livecode-boun...@lists.runrev.com
[mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Dar Scott
Sent: Thursday, September 29, 2011 12:39 PM
To: How to use LiveCode
Subject: Re: Reading PDF - a cry for help
I see three directions to pulling images out of PDF files on Windows:
1. Use a command-line utility and shell() plus file I/O
2. Loosely parse the PDF file
3. Create an external
I recommend starting with #1 and seeing how it works for you. All are
possible.
Dar
On Sep 29, 2011, at 8:01 AM, Graham Samuel wrote:
Folks, for some months now (it seems even longer) I have been seeking a
solution to the problem of reading PDF-formatted images into Livecode
stacks. What I'm looking for is solution that looks like an 'import paint'
command: in other words, I want to be able to load a small subset of the
possible contents of a PDF - just bitmap images - into a stack via script.
Sadly I want to do this on a PC, running at a minimum Windows XP. My users
want a simple solution that makes reading from a PDF no more complicated
than reading a JPG.
I have explored several possibilities, including using a 'free' PDF reader
that is somehow hidden from the user of my app, and using say 'shell' to
control it and to pass an image to LiveCode. However I have not found a
realistic way of doing this, particularly when I include the need to have a
very simple installation process - the user should not see any additional
application, nor be obliged to provide substantial additional resources, as
would be true for example if one used ImageMagick in this way in a PC
context.
Short of RunRev itself extending input formats to include PDF (not
impossible, but not likely in the short term), the solution would seem to be
to licence a third-party library component and integrate it into my app by
the use of bridging ('glue') code. I got pretty near with this one, having
identified a component with suitable licensing terms and functionality
(Sorax DLL). RunRev suggested that I could do the gluing with the aid of a
'C' programmer. It turns out after a lot of research by Thierry Douez, who
has been helping me, that what I need is a person familiar with Visual
Studio to accomplish this - but I despair of finding such a person who would
also be familiar with the externals interface of the LiveCode engine. Maybe
I will find such a person, but the trail does seem to have gone cold.
Has anyone any suggestion as to how I might proceed? My app works so
nicely with JPG and PNG files, and I have (a little) belief that I could
make it work with TIFF files, but without PDF input I am dead in the water.
TIA
Graham
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
---
Dar Scott
dba
Dar Scott Consulting
8637 Horacio Place NE
Albuquerque, NM 87111
Lab, home, office phone: +1 505 299 9497
For Skype and fax, please contact.
d...@swcp.com
Computer Programming and tinkering,
often making LiveCode libraries and
externals, sometimes writing associated
microcontroller firmware.
---
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
I just created a PDF with two lines of text and a 16x16 graphic and following text. A very basic test pattern. Then I opened up the document in BBEdit. Yikes! A huge amount of data is there - some binary and some plain text for such simple data. A minefield of fun and a big project to work with. Here's the specs ( a large PDF document) right from the source. PDF SPECS DOCUMENThttp://partners.adobe.com/public/developer/en/pdf/PDFReference.pdf Good luck. On 29 September 2011 10:11, Dar Scott d...@swcp.com wrote: There are command-line utilities that will take a pdf page and render it onto an image and store the image as a standard file. Some work with multiple page documents. These can work with the LiveCode shell() function. Dar On Sep 29, 2011, at 11:02 AM, Joe Lewis Wilkins wrote: I find all of this somewhat tantalizing, but the only way I've found to make a PDF document useful in what I'm doing is to take a screen shot of it and then paste or import it as an image into the other application. Though I do this mostly in MacDraft, I should imagine that the same technique can be used in LC, since I often use MD as a method of transitioning different kinds of images into LC. Of course I'm interested in what you see in a PDF; not what else there might be there, of which I know nothing. I don't understand all of this parsing of data from or in a PDF. Joe Wilkins On Sep 29, 2011, at 9:50 AM, Dar Scott wrote: On Sep 29, 2011, at 9:24 AM, Ken Ray wrote: Are you looking at just extracting the images? Or other relevant parts of the PDF? The reason I ask is that it looks like binary data is always contained between two lines: stream and endstream, so extracting just the streaming data should be pretty quick to do; although the next step would be going to read the bytes of what was extracted and then determine if it's an image or some other thing that had to be represented with a stream in the PDF... There are a couple issues that complicate this in general. The parameters needed to process the stream need to be parsed and they can be far away. There are many stream filters (some complicated compression) and they can be nested. I looked at a corpus of PDF files and, yeah, a several are used in practice. However, if one needs to parse the output of a specific program or a specific model of a scanner, then the work to do parsing in LiveCode is a lot less. I hope that makes sense; I'm a little under the weather today. Dar ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode --- Dar Scott dba Dar Scott Consulting 8637 Horacio Place NE Albuquerque, NM 87111 Lab, home, office phone: +1 505 299 9497 For Skype and fax, please contact. d...@swcp.com Computer Programming and tinkering, often making LiveCode libraries and externals, sometimes writing associated microcontroller firmware. --- ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Stephen Barncard San Francisco Ca. USA more about sqb http://www.google.com/profiles/sbarncar ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Thanks Stephen. I'll take a look at Clairfy. MD provides DWG and DXF translations, but I rarely have need for them, avoiding AutoCAD like the plague as I always have, though I've heard they're going to come back to the Mac shortly. Maybe already. I've been a beta tester for MD for about 15 years. Joe Wilkins On Sep 29, 2011, at 10:19 AM, stephen barncard wrote: Not sure about your needs but... You can save a lot of time between MacDraft and PDFs by using Blue Mango's wonderful and fully supported Clairfy. Select, copy to PDF in one step with annotations available and online distribution if you want. It's FREE and highly recommended. Get Clarify HERE http://www.bluemangolearning.com/clarify/ If your work includes MacDraft, you should know about the (Autocad standard) DWG/DXF import and export feature. It is all plain text and human readable, with point, line and position data that some of which could be turned into corresponding LC commands. But it might be easier to just use Clarify. It's really good. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
On 09/29/2011 12:27 PM, stephen barncard wrote: I just created a PDF with two lines of text and a 16x16 graphic and following text. A very basic test pattern. Then I opened up the document in BBEdit. Yikes! A huge amount of data is there - some binary and some plain text for such simple data. A minefield of fun and a big project to work with. Here's the specs ( a large PDF document) right from the source. PDF SPECS DOCUMENThttp://partners.adobe.com/public/developer/en/pdf/PDFReference.pdf Good luck. But it should certainly be doable. In fact, File Juicer does it. It's Mac software, but it is an example of exactly what is being discussed. It might be a lot of work, but clearly it's not a hopeless task :) Best, Warren ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Joe, yes. MD is a great product. It was the first piece of Mac software I ever purchased in 1987. In fact, for a moment in testing in a Egghead software store, I could have gone to either platform. I asked to see a PC product and MacDraft. There was no comparison. I bought MacDraft and spec'd macs for AM studios the next day. AutoCad for mac is already here FREE TRIALhttp://usa.autodesk.com/adsk/servlet/download/item?id=17335606siteID=123112ch=ONsrc=OMSEmktvar001=353376mktvar002=353376utm_source=Googleutm_medium=cpcutm_term=mac%20autocadutm_content=Mac%20Broadutm_campaign=Autodesk%20-%20AutoCAD%20for%20the%20Mac On 29 September 2011 10:40, Joe Lewis Wilkins pepe...@cox.net wrote: Thanks Stephen. I'll take a look at Clairfy. MD provides DWG and DXF translations, but I rarely have need for them, avoiding AutoCAD like the plague as I always have, though I've heard they're going to come back to the Mac shortly. Maybe already. I've been a beta tester for MD for about 15 years. Joe Wilkins On Sep 29, 2011, at 10:19 AM, stephen barncard wrote: Not sure about your needs but... You can save a lot of time between MacDraft and PDFs by using Blue Mango's wonderful and fully supported Clairfy. Select, copy to PDF in one step with annotations available and online distribution if you want. It's FREE and highly recommended. Get Clarify HERE http://www.bluemangolearning.com/clarify/ If your work includes MacDraft, you should know about the (Autocad standard) DWG/DXF import and export feature. It is all plain text and human readable, with point, line and position data that some of which could be turned into corresponding LC commands. But it might be easier to just use Clarify. It's really good. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Stephen Barncard San Francisco Ca. USA more about sqb http://www.google.com/profiles/sbarncar ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
On 9/29/2011 10:01 AM, Graham Samuel wrote:
Short of RunRev itself extending input formats to include PDF (not impossible,
but not likely in the short term), the solution would seem to be to licence a
third-party library component and integrate it into my app by the use of
bridging ('glue') code. I got pretty near with this one, having identified a
component with suitable licensing terms and functionality (Sorax DLL). RunRev
suggested that I could do the gluing with the aid of a 'C' programmer. It turns
out after a lot of research by Thierry Douez, who has been helping me, that
what I need is a person familiar with Visual Studio to accomplish this - but I
despair of finding such a person who would also be familiar with the externals
interface of the LiveCode engine. Maybe I will find such a person, but the
trail does seem to have gone cold.
Has anyone any suggestion as to how I might proceed? My app works so nicely
with JPG and PNG files, and I have (a little) belief that I could make it work
with TIFF files, but without PDF input I am dead in the water.
As some folks may remember, I have posted to this list a number of time
on the need for being able to open and read PDF content (text and
images) in LiveCode. We at Researchware have, I think, thoroughly
explored this topic. It all boils down to the fact you need 3rd party
technology that can read the PDF format and render it and/or extract the
text from it.
For pages as images or unstylized text, the cheap and dirty way is to
use a 3rd party command-line utility to make your conversions. From a
script perspective, you perform an answer file command, get the PDF
file, and then use shell to batch convert it and then read the resulting
text file or image file(s) back in. There is NO other free way to do
this. Yes, this is ugly and probably not for the novice scripter and you
code pretty much has to be platform specific, but again, it is the ONLY
free way to do this. You are also not every displaying a real PDF - you
are either displaying images of pages OR the unformatted, unstyled text.
You can also do a limited form of displaying a PDF in a window (you
can't get or copy any selections/content in it though and can only
navigate under script control by page) through InterApplication
communication (IAC)
To open a PDF in LiveCode where you can actually control navigation
through script control and get or set the user selections required two
things: (a) a PDF library with APIs supporting these actions and (b)
creating a set of LiveCode externals that in turn use the PDF APIs to
provide these functions. The main problem with this approach is that all
(or all we could find) of the open source or free PDF libraries are
woefully immature and lack major functionality. Only commercial PDF
technology has the supported APIs for this and whether Adobe, Foxit or
other commercial PDF technologies providers, all charge typically based
upon a per unit shipped royalty model. And some, like Adobe, are really
expensive.
I used the revPartner program to explore this with RunRev quite some
time ago and asked whether they would consider support in the engine. At
the time, they only said it was not practical due to licensing issues
(or close to that). What I understand now is that is becuase the open
source PDF libraries are crap and the commercial ones woudlld have
imposed an entirely different licensing model for LiveCode - one with
runtime royalties - which I think none of us want (RunRev or Developers).
I am afraid, as of September 2011, that is that state of LiveCode and
PDFs. There is a promising free open source GNU effort out there
(http://gnupdf.org/Library), but most of the libraries are only 30 or
40% complete. When this is complete, we can all benefit from free PDF
support in LiveCode by wrapping the external API around the GNU effort.
Until then, you have to choose between cheap, dirty, and limited OR
costly and commercial.
--
Paul Dupuis
Cofounder
Researchware, Inc.
http://www.researchware.com/
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Stephen, I can see I'm talking to the choir. (smile) For a couple of years MD was side-tracked into Dreams before Micro-spot purchased it from IDD? Sometimes it's been a bumpy road, but I rarely have to use much of anything else. At first glance Clarify looks awesome. What is AM Studios? A design firm? Joe Wilkins Architect On Sep 29, 2011, at 10:52 AM, stephen barncard wrote: Joe, yes. MD is a great product. It was the first piece of Mac software I ever purchased in 1987. In fact, for a moment in testing in a Egghead software store, I could have gone to either platform. I asked to see a PC product and MacDraft. There was no comparison. I bought MacDraft and spec'd macs for AM studios the next day. AutoCad for mac is already here FREE TRIALhttp://usa.autodesk.com/adsk/servlet/download/item?id=17335606siteID=123112ch=ONsrc=OMSEmktvar001=353376mktvar002=353376utm_source=Googleutm_medium=cpcutm_term=mac%20autocadutm_content=Mac%20Broadutm_campaign=Autodesk%20-%20AutoCAD%20for%20the%20Mac On 29 September 2011 10:40, Joe Lewis Wilkins pepe...@cox.net wrote: Thanks Stephen. I'll take a look at Clairfy. MD provides DWG and DXF translations, but I rarely have need for them, avoiding AutoCAD like the plague as I always have, though I've heard they're going to come back to the Mac shortly. Maybe already. I've been a beta tester for MD for about 15 years. Joe Wilkins On Sep 29, 2011, at 10:19 AM, stephen barncard wrote: Not sure about your needs but... You can save a lot of time between MacDraft and PDFs by using Blue Mango's wonderful and fully supported Clairfy. Select, copy to PDF in one step with annotations available and online distribution if you want. It's FREE and highly recommended. Get Clarify HERE http://www.bluemangolearning.com/clarify/ If your work includes MacDraft, you should know about the (Autocad standard) DWG/DXF import and export feature. It is all plain text and human readable, with point, line and position data that some of which could be turned into corresponding LC commands. But it might be easier to just use Clarify. It's really good. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
You can also do a limited form of displaying a PDF in a window (you can't get or copy any selections/content in it though and can only navigate under script control by page) through InterApplication communication (IAC) Yes, I think this can actually be done with a Player object too, but it gives you the same results (no selection/content). To open a PDF in LiveCode where you can actually control navigation through script control and get or set the user selections required two things: (a) a PDF library with APIs supporting these actions and (b) creating a set of LiveCode externals that in turn use the PDF APIs to provide these functions. The main problem with this approach is that all (or all we could find) of the open source or free PDF libraries are woefully immature and lack major functionality. Only commercial PDF technology has the supported APIs for this and whether Adobe, Foxit or other commercial PDF technologies providers, all charge typically based upon a per unit shipped royalty model. And some, like Adobe, are really expensive. Is it possible to open a PDF in a revBrowser control? That *should* (theoretically) give you the same ability as you have with a regular web browser - although you may not be able to get the text of the selection in any meaningful way... Ken Ray Sons of Thunder Software, Inc. Email: k...@sonsothunder.com Web Site: http://www.sonsothunder.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Please excuse my 1998 web design. Hip at the time, pretty lame today. On 29 September 2011 11:19, stephen barncard stephenrevoluti...@barncard.com wrote: http://amstudios.net/amstudios.html On 29 September 2011 11:08, Joe Lewis Wilkins pepe...@cox.net wrote: anything else. At first glance Clarify looks awesome. What is AM Studios? A design firm? Joe Wilkins Architect Stephen Barncard San Francisco Ca. USA more about sqb http://www.google.com/profiles/sbarncar ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Reading PDF - a cry for help
Stephen, Evolution in all things. (smile) Unfortunately, most of my design errors have at least 50 years before they will fade away, although I recently drove past a site in Laguna Niguel where I had designed a Nursery in 1968 and found it had been replaced by a new bank. Price of land! And a low cost FHA housing project in Vista done about the same time should be torn down. It's falling apart due to neglect. Architecture is a fun profession to see work you can remember doing 30 and 40 years ago still being useful, though not always up to current standards. Since I engineer all of my own buildings, in Southern California it is gratifying to see that they are still standing. Now if the Economy will just rebound! I graduated from Cal in 1959, so I'm familiar with S.F. from my Summer Jobs. Joe Wilkins Architect On Sep 29, 2011, at 11:27 AM, stephen barncard wrote: Please excuse my 1998 web design. Hip at the time, pretty lame today. On 29 September 2011 11:19, stephen barncard stephenrevoluti...@barncard.com wrote: http://amstudios.net/amstudios.html On 29 September 2011 11:08, Joe Lewis Wilkins pepe...@cox.net wrote: anything else. At first glance Clarify looks awesome. What is AM Studios? A design firm? Joe Wilkins Architect Stephen Barncard San Francisco Ca. USA more about sqb http://www.google.com/profiles/sbarncar __ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
