| |||||||||||||
Thanks for the heads upThanks for the heads upPosted Mar 30, 2005 19:53 UTC (Wed) by b7j0c (subscriber, #27559)Parent article: Unexpected features in Acrobat 7
One more reason why open software is so important, little tricks like this come out earlier and easier, no need for forensic analysis (thankfully the author to the time to do the work).
If in fact future open pdf readers want to support JS, it would be nice to be able to disable this feature...I can think of no circumstances in which I feel I need to alert an author to the fact that I have opened their document.
(Log in to post comments)
Thanks for the heads up Posted Mar 30, 2005 21:13 UTC (Wed) by fjf33 (subscriber, #5768) [Link] In gentoo it will probably be USE=-javapdf and it won't be compiled in. :)
Thanks for the heads up Posted Mar 31, 2005 18:54 UTC (Thu) by dberkholz (subscriber, #23346) [Link] Acroread is distributed as a precompiled binary.
Thanks for the heads up Posted Mar 30, 2005 21:53 UTC (Wed) by iabervon (subscriber, #722) [Link] Ideally, they would support JavaScript, but allow the user to put limits on what it is allowed to do. I could see a use to having a tax form PDF run the calculations as you fill it out, while you wouldn't want to let it make network connections.
Thanks for the heads up Posted Mar 31, 2005 15:05 UTC (Thu) by gnb (subscriber, #5132) [Link] I'm not that convinced about the need for Javascript, myself:1) Take a procedural page layout language (PostScript) 2) Hack out the procedural bits so you're just left with the display bits you need to draw documents and call the result PDF 3) Add in support for a completely unrelated procedural language so you can have interactive documents Yes, I know more people can write Javascript than PS, but the whole thing still seems... icky.
Thanks for the heads up Posted Mar 31, 2005 17:49 UTC (Thu) by iabervon (subscriber, #722) [Link] Postscript, even without the procedural bits hacked out, doesn't really have an interaction model. So it would have to be substantially replaced anyway in order to be useful, and then there's still the fact that it's a stack language, which is an obscure class of language.
I suspect that xhtml, xforms, and a spreadsheet-style expression language would apply better to the actual useful applications, but people persist in going for Turing-complete solutions instead of more targetted ones.
Thanks for the heads up Posted Mar 31, 2005 23:16 UTC (Thu) by gnb (subscriber, #5132) [Link] >Postscript, even without the procedural bits hacked out, doesn't really> have an interaction model. There's Display PostScript, which addressed this long before Javascript. But yes, the point about not really needing a Turing-complete language in the first place is a good one.
Thanks for the heads up Posted Mar 31, 2005 23:20 UTC (Thu) by dvdeug (subscriber, #10998) [Link] A spreadsheet is Turing complete. Most useful forms of computation are Turing-complete; it really doesn't take that much to be, and if you aren't Turing-complete, you very quickly run into problems you want to solve that you can't. Even most Unix "regexs" aren't really computer science regular expressions; they're Turing-complete.
Thanks for the heads up Posted Mar 31, 2005 23:30 UTC (Thu) by gnb (subscriber, #5132) [Link] I'm not sure "useful" quite captures it. "Accessible" may be closer:I've had explanations from computer scientists about how to solve a problem in a language that's more limited, and yes the answer works, but it usually requires far more cleverness than coming up with a solution to the same problem in a Turing-complete language. That is, yes Turing-completeness is often overkill, but it's overkill that makes solving the problem so much _easier_.
Thanks for the heads up Posted Apr 1, 2005 14:19 UTC (Fri) by iabervon (subscriber, #722) [Link] If you require cell references to be acyclic, don't have document-defined functions or don't let them be recursive, and don't have unbounded looping constructs, it's obviously not Turing-complete, because every calculation has to halt. I think this is still sufficient for the applications people will expect to use a form for, assuming the library is satisfactory. I believe that the expectation would be that you have a form such that you could fill it out completely yourself (if you printed it out, for example), but some of the fields depend on other fields, and the software will fill in these fields for you if you fill in the necessary other fields.
Complicated as it is, the US tax code (for example) is written with constraints which make the language of potential tax codes not Turing-complete (not counting things you do to acquire the inputs to the tax code; the process of getting a 1099 from a bank may not terminate, but doing your taxes once you have all the necessary documents will). This is the sort of thing that people would like to automate: forward-only calculations with a finite number of steps and an acyclic inclusion of worksheets.
Thanks for the heads up Posted Apr 1, 2005 7:02 UTC (Fri) by khim (subscriber, #9252) [Link] :roll: It's not so easy to develop non-turing-complete system without artificial limits. DVD-Video is not turing-complete, for example. The reason is not obscurity of format but trivial fact that it only has limited number of registers (20 plus some special ones with user-visible effects).
This is turing-complete "langauge"!
|
|||||||||||||