RE: PDF as normative reference (was RE: HTMLImageElement -- use of SVG within <canvas>)

Done.   Bug# 12570 (<http://www.w3.org/Bugs/Public/show_bug.cgi?id=12570>)

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Thursday, April 28, 2011 11:54 PM
To: Leonard Rosenthol
Cc: Dailey, David P.; public-html@w3.org
Subject: Re: PDF as normative reference (was RE: HTMLImageElement -- use of SVG within <canvas>)


Good suggestion. I recommend filing a bug at <http://www.w3.org/Bugs/Public/>.

Regards,
Maciej

On Apr 28, 2011, at 8:27 PM, Leonard Rosenthol wrote:

> [yes, I should probably file this as a bug, but figured I'd note it here]
> 
> On a related note, it appears that PDF is mentioned in about 20 times in the HTML5 spec of which about 7 or 8 of them are in normative text (such as the one below on HTMLImageElement).
> 	
> However, I see no reference that defines PDF.  I would, of course, recommend that you use ISO 32000-1:2008 as that reference since it is the international standard.  BUT since I also know that the W3C has concerns over "pay-for-access" documents, I  would note that Adobe distributes a FREE version of ISO 32000-1 (by agreement with ISO).  That document can be found at <http://www.adobe.com/devnet/acrobat/pdfs/PDF32000_2008.pdf> and would be the link to use.
> 
> Making this simple change will then ensure that there is no question about what developers should be using if/when implementing support for PDF in their products.
> 
> 
> Leonard Rosenthol  |  PDF Architect |  Adobe Systems Incorporated  |  p. 408.657.PDFS | leonardr@adobe.com
> 
> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Dailey, David P.
> Sent: Thursday, April 28, 2011 4:54 PM
> To: public-html@w3.org
> Subject: HTMLImageElement -- use of SVG within <canvas>
> 
> The drawImage method of <canvas> should be able to take an HTMLImageElement as its image argument.
> 
> An HTMLImageElement should include
> 
> "Images can thus be static bitmaps (e.g. PNGs, GIFs, JPEGs), single-page vector documents (single-page PDFs, XML files with an SVG root element), animated bitmaps (APNGs, animated GIFs), animated vector graphics (XML files with an SVG root element that use declarative SMIL animation), and so forth. However, this also precludes SVG files with script, multipage PDF files, interactive MNG files, HTML documents, plain text documents, and so forth."
> 
> I assume there are good reasons for excluding SVG files with script; at least I am certain that careful thought went into that stipulation, and will assume the thinking was cogent.
> 
> However, it would be nicer, I think, to allow one to reference an SVG file that happens to have script, and to render the image, but simply not to require the script to be run.
> 
> See for example:
> 
> http://srufaculty.sru.edu/david.dailey/svg/recent/htmlsvgcanvas7b.htm
> 
> It runs "properly" in no extant browser, that I'm aware of.
> 
> The SVG file in question contains only the following script:
> 
> <script><![CDATA[
> ]]>
> </script>
> 
> which is sort of a generic boilerplate oftentimes included in SVG files, should they need, later on to be scripted.
> 
> On the other hand, the above file, when referencing a JPEG rather than an SVG runs "properly" in all modern browsers I've tested. (IE9, Chrome, FF4, Opera, and Safari): http://srufaculty.sru.edu/david.dailey/svg/recent/htmlsvgcanvas7a.htm
> 
> Instead of "precluding" SVG with script, could we instead include "XML files with an SVG root element" (as is already stated) and simply add that browsers are not required to support (or even are precluded from running if that makes sense for security reasons) scripting associated with the SVG DOM of such images?
> 
> regards,
> David
> 
>

Received on Friday, 29 April 2011 14:25:58 UTC