[Sugar-devel] Deployment feedback braindump

[Tomeu Vizoso]

On Wed, Aug 12, 2009 at 20:29, Lucian Branescu<lucian.branescu at gmail.com> wrote:
> 2009/8/12 Albert Cahalan <acahalan at gmail.com>:
>> On Wed, Aug 12, 2009 at 10:16 AM, Lucian
>> Branescu<lucian.branescu at gmail.com> wrote:
>>> 2009/8/12 Bernie Innocenti <bernie at codewiz.org>:
>>>> El Wed, 12-08-2009 a las 13:28 +0100, Lucian Branescu escribió:
>>
>>>>> JavaScript-in-PDF is mostly a joke and a big security risk. It's not
>>>>> something to be relied upon.
>>>>
>>>> It might be useless, but I don't see why it should be more risky than
>>>> Javascript in web browsers, which everybody happily accepted without
>>>> much thought.  Is JS in PDF even allowed to make HTTP connections?
>>>
>>> JavaScript in PDF is more risky because the sandboxing isn't as mature
>>> as the one in web browsers. It should theoretically be at least as
>>> safe, but in practice it isn't. This is mostly a problem with adobe's
>>> implementation, which is an absolute train-wreck, but other
>>> implementers without browser sandboxing experience might repeat some
>>> mistakes.
>>
>> Anybody sane would just grab a mature engine from a browser.
>>
>> The recent supposed JavaScript problems in Acrobat are nothing
>> more than heap spraying; there are at least two non-JavaScript ways
>> to do that. The exploit was recently redone w/o any JavaScript.
>>
>> Note that PDF, being essentially postscript, already comes with
>> a full programming language. That's what postscript **is**.
>
> So what's the point of JavaScript in PDFs then?

Lucian, Albert and Bernie,

could you please change the subject line when you want to talk about
something totally unrelated to the original thread?

Thanks,

Tomeu

>>
>>>> How do you dubmit the form?  By HTTP?  Does the PDF reader tell the user
>>>> when it's going to make this connection?
>>>
>>> You would submit the form by sending back the completed PDF file. It's
>>> a bit awkward, but it works.
>>>
>>> Ideally, people should be using HTML forms, those are made to be
>>> easily and seamlessly submitted.
>> ...
>>> In any case, PDF is a good presentation format. Why make it
>>> significantly more complex for small-to-none improvements to its main
>>> purpose?
>>
>> PDF forms often look attractive. HTML forms normally look ugly.
>> This is because PDF is a good presentation format. HTML is not.
>>
>
> This of course depends on your browser. I think HTML forms look great,
> but that's because I use OS X or KDE.
>
>> Printing a PDF form to fill it out the old-fashioned way is reasonable.
>> You can even fill most of it out, print it, and then sign it or stamp it.
>> With HTML this really isn't practical.
>
> You can do it with HTML and it would be perfectly practical if there
> were a format based on a HTML subset that specified printable forms.
> That would be moot though, since PDF is much better at printables
> already.
>
>>
>> In the case of math worksheets, the child really needs a way to
>> scribble on the document. This is for handwriting practice and to
>> allow arbitrary free-form drawing and layout. PDF can provide this,
>> either via printing or via wrapping extra postscript code around the
>> document. To do this in HTML you'd have to write a custom app
>> in JavaScript, Java, or flash -- none of which is really HTML at all.
>>
>
> You could indeed do it on PDF only, like Okular and Preview (OS X) can
> annotate PDFs. But you could do it with HTML & JS, with the html5
> <canvas> (JS is HTML's native programming language, equivalent to PS).
> The drawback to the second is, as with printing, that HTML is very
> general. An easily printable subset of HTML would be needed for this.
>
>
> I believe JavaScript in PDF to be useless bloat. PostScript should be
> enough for all PDF needs. If it isn't, then PDF is probably the wrong
> format to use.
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>