Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
On Thu, Jan 3, 2013 at 10:32 PM, Steve Block stevebl...@chromium.orgwrote: I find point - point = size quite useful in general, and it seems to make logical sense. I agree that it makes logical sense, but I think that 'point - point = point' also makes sense, and is perhaps more frequently the right choice. What would you call this type, avoiding confusion with Vector? I guess 'Offset' is an obvious candidate, but that is probably already too overloaded. Perhaps RelativePosition or RelativePoint? I don't think Relative adds any value here. Also, the word position is used to represent a tree-position in DOM in WebKit so please don't use that to represent a point in a screen or a layout coordinate system. I don't like offset either because it's such an overloaded word. e.g. offset is often used to mean a child node index in DOM. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] YARR example
Thanks for your reply! I already figured out how to make a case sensitive replacement with String::replace, which works exactly as I wanted. However case-insensitive replacement with (?i) doesn't work at all. Is this implementation specific, do I need to use other notation to indicate case insensitive matching? Regards, Ognian On Thu, Jan 3, 2013 at 6:28 PM, Michael Saboff msab...@apple.com wrote: Ognian, YARR is the regular expression engine for the JavaScriptCore part of webkit. It can find the matches, but you would need to write other C++ code to do the replacement. The String.replace() method will do what you want in JavaScript. - Michael On Jan 3, 2013, at 4:16 AM, Ognian Milanov ogi.andr...@gmail.com wrote: Hello! I need info how to use YARR to replace all matches of a given regular expression in a string with another string. For example in Java this is achieved by String.replaceAll method. I will appreciate if someone leads me to the solution, thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
I think this feature was rushed in the spec. Can we hold off submitting this until people have a chance to think it through? It seems innocent enough to make this part of the graphic state but I believe this is the wrong place (since no graphic library except cairo did it this way) and will give us problems down the line. On Thu, Jan 3, 2013 at 3:40 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 2 Jan 2013, James Ascroft-Leigh wrote: There has been a proposal that a new property is added to the canvas 2D drawing context called fillRule with values nonzero (default) and evenodd. This is compatible with the mozFillRule already implemented in Mozilla Firefox and would be on track to become a web standard. If you are interested in knowing more I suggest you start with the bug I raised and take a look at the patch. https://bugs.webkit.org/show_bug.cgi?id=105508 This is now in the spec. http://whatwg.org/html/#dom-context-2d-fillrule -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] YARR example
Ognian, For the search to be case insensitive, you add an 'i' to the end of the regular expression. The replace will be whatever string to have for the second argument. See http://www.w3schools.com/jsref/jsref_replace.asp for an example of case-insensitive search/replace. - Michael On Jan 4, 2013, at 1:57 AM, Ognian Milanov ogi.andr...@gmail.com wrote: Thanks for your reply! I already figured out how to make a case sensitive replacement with String::replace, which works exactly as I wanted. However case-insensitive replacement with (?i) doesn't work at all. Is this implementation specific, do I need to use other notation to indicate case insensitive matching? Regards, Ognian On Thu, Jan 3, 2013 at 6:28 PM, Michael Saboff msab...@apple.com wrote: Ognian, YARR is the regular expression engine for the JavaScriptCore part of webkit. It can find the matches, but you would need to write other C++ code to do the replacement. The String.replace() method will do what you want in JavaScript. - Michael On Jan 3, 2013, at 4:16 AM, Ognian Milanov ogi.andr...@gmail.com wrote: Hello! I need info how to use YARR to replace all matches of a given regular expression in a string with another string. For example in Java this is achieved by String.replaceAll method. I will appreciate if someone leads me to the solution, thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Review Request: MIPS patches for LLINT and DFG
Dear Webkit Developers, We submitted MIPS implementations for LLINT and the DFG JIT. We also kept the patches rebased as the webkit-trunk moved forward, the latest update of the patches were uploaded today. 1. LLINT: https://bugs.webkit.org/show_bug.cgi?id=99706 Filip Pizlo was very helpful with refactoring LLINT to better accommodate the different RISC-like architectures. The latest versions of this patch already use this new infrastructure of the offline assembler (risc.rb). 2. DFG JIT: https://bugs.webkit.org/show_bug.cgi?id=101328 We also implemented the DFG JIT for MIPS. However, unfortunately we did not receive any review comments for it yet. 3. We also have another pending patch, which is not MIPS specific, but a fix to the style checker which should help anyone who is submitting patches with asm() statements: https://bugs.webkit.org/show_bug.cgi?id=101367 This patch has also attracted no review comments so far. Could anyone please help us in getting these patches reviewed, and (hopefully) accepted into webkit trunk? Please let us know if we are not properly following the contribution process. Thank you for your support, Gergely ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
Subtraction of two points should not equate to a size. That's would be unexpected behavior for anyone used to working in 2D space. Mathematically speaking point - point equates to a vector. When writing a vector math library there typically isn't a differentiation made between a point and a vector, mainly because there's a lot of code overlap between the two. However when they do for 3D values a point is x, y, z, 1 while a vector is x, y, z, 0. On a somewhat unrelated note is there any interest in getting a SIMD implementation of these classes? From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Ryosuke Niwa Sent: Friday, January 04, 2013 12:19 AM To: Steve Block Cc: WebKit-Dev Development Subject: Re: [webkit-dev] Int/FloatPoint and Int/FloatSize On Thu, Jan 3, 2013 at 10:32 PM, Steve Block stevebl...@chromium.orgmailto:stevebl...@chromium.org wrote: I find point - point = size quite useful in general, and it seems to make logical sense. I agree that it makes logical sense, but I think that 'point - point = point' also makes sense, and is perhaps more frequently the right choice. What would you call this type, avoiding confusion with Vector? I guess 'Offset' is an obvious candidate, but that is probably already too overloaded. Perhaps RelativePosition or RelativePoint? I don't think Relative adds any value here. Also, the word position is used to represent a tree-position in DOM in WebKit so please don't use that to represent a point in a screen or a layout coordinate system. I don't like offset either because it's such an overloaded word. e.g. offset is often used to mean a child node index in DOM. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
On Fri, Jan 4, 2013 at 12:15 AM, Simon Fraser simon.fra...@apple.comwrote: On Jan 3, 2013, at 7:43 PM, Steve Block wrote: Thanks all for the detailed replies. I wasn't aware of the distinction made between points and vectors for the purposes transforms. However, if I understand things correctly, introducing a vector type could be considered separately from the issue I initially raised. It seems that everyone is agreed that xxxSize should be used only when you really want to represent a size. A good first step would be trying to enforce this, such that all points and vectors are represented with xxxPoint. As Shawn points out, when doing this, we need to make sure that we continue to use the correct homogeneous coordinate for transforms. Removing the existing subtraction operator (xxxPoint minus xxxPoint returns xxxSize) might be a good place to start. I find point - point = size quite useful in general, and it seems to make logical sense. Introducing the concept of a vector could then be done in a second phase. What would you call this type, avoiding confusion with Vector? In chromium we recently added such a class with the name Vector2d, to differentiate it from std::vector. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Fri, 4 Jan 2013, Rik Cabanier wrote: I think this feature was rushed in the spec. The specing is usually the first step. You can't rush to spec. :-) In this particular case, though, it was the third or fourth step. The discussion has been open since June 2011. It's not like people didn't have time to comment. It's been shipping in a browser for over a year. Any solution we come up with to the issues that were raised regarding Path will almost certainly be done in a way that builds on context.fillRule, not in a way that removes context.fillRule. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Jan 2013, Rik Cabanier wrote: I think this feature was rushed in the spec. The specing is usually the first step. You can't rush to spec. :-) In this particular case, though, it was the third or fourth step. The discussion has been open since June 2011. It's not like people didn't have time to comment. It's been shipping in a browser for over a year. Any solution we come up with to the issues that were raised regarding Path will almost certainly be done in a way that builds on context.fillRule, not in a way that removes context.fillRule. I was not aware of that discussion. There are good reasons to make the fill rule part of the fill operation itself. It does not make sense in the graphic state. How about EOClip? That is a construct that is far more used than eofill. Will that get its own parameter too? How about the interaction of stroking and this parameter (if you follow the spec's wording for stroking)? How about ispointinpath? Will that follow the winding rule in the graphic state? How about hit regions? How can you specify the winding there? It's better to follow what almost every other graphics library has done: Add an EOFill and an EOClip. I volunteer to add it to Mozilla if it helps. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Fri, 4 Jan 2013, Rik Cabanier wrote: How about EOClip? That is a construct that is far more used than eofill. Will that get its own parameter too? As specced it uses the same parameter. How about the interaction of stroking and this parameter (if you follow the spec's wording for stroking)? https://www.w3.org/Bugs/Public/show_bug.cgi?id=20569 How about ispointinpath? Will that follow the winding rule in the graphic state? That's what the spec says currently, yes. How about hit regions? How can you specify the winding there? https://www.w3.org/Bugs/Public/show_bug.cgi?id=20558 It's better to follow what almost every other graphics library has done: Add an EOFill and an EOClip. This is the wrong mailing list to argue this, but in general I don't see why it's better. Just asserting that it is, or that other platforms do it, is not compelling. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Jan 4, 2013, at 5:24 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Jan 2013, Rik Cabanier wrote: I think this feature was rushed in the spec. The specing is usually the first step. You can't rush to spec. :-) In this particular case, though, it was the third or fourth step. The discussion has been open since June 2011. It's not like people didn't have time to comment. It's been shipping in a browser for over a year. Any solution we come up with to the issues that were raised regarding Path will almost certainly be done in a way that builds on context.fillRule, not in a way that removes context.fillRule. I was not aware of that discussion. There are good reasons to make the fill rule part of the fill operation itself. It does not make sense in the graphic state. How about EOClip? That is a construct that is far more used than eofill. Will that get its own parameter too? It will use the same property, since there is no difference. That is why the name could be a bit misleading. windingRule would be a bit more independent of the fill operation. How about the interaction of stroking and this parameter (if you follow the spec's wording for stroking)? This needs to change as well to match the new behavior. This is more a specification problem and no implementation problem. How about ispointinpath? Will that follow the winding rule in the graphic state? It would depend on the fillRule that you set on the context. How about hit regions? How can you specify the winding there? This is a good point. But it depends if hit region will be implemented as specified. It's better to follow what almost every other graphics library has done: Add an EOFill and an EOClip. I volunteer to add it to Mozilla if it helps. That is not fully correct. Just Qt and Skia make it explicitly on the Path object (which is not necessarily depending on the fill operation itself). CG does not bundle EOfill with a path, instead you set it during painting. Which is partly as done by the specification, with the exception that it is not part of the graphic state, but also not part of the path logic. Cairo graphics has the fill rule as part of the graphic state IIRC. This discussion is a bit misplaced on webkit-dev. Could you continue it on the WHAT WG mailing list please? I would just agree with Rik here, that we should wait a bit more time before implementing it in WebKit. Even if following the Firefox implementation and the needs of PDF.js is a good reason for implementing as suggested by the spec. Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Fri, Jan 4, 2013 at 5:42 PM, Dirk Schulze dschu...@adobe.com wrote: On Jan 4, 2013, at 5:24 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Jan 2013, Rik Cabanier wrote: I think this feature was rushed in the spec. The specing is usually the first step. You can't rush to spec. :-) In this particular case, though, it was the third or fourth step. The discussion has been open since June 2011. It's not like people didn't have time to comment. It's been shipping in a browser for over a year. Any solution we come up with to the issues that were raised regarding Path will almost certainly be done in a way that builds on context.fillRule, not in a way that removes context.fillRule. I was not aware of that discussion. There are good reasons to make the fill rule part of the fill operation itself. It does not make sense in the graphic state. How about EOClip? That is a construct that is far more used than eofill. Will that get its own parameter too? It will use the same property, since there is no difference. That is why the name could be a bit misleading. windingRule would be a bit more independent of the fill operation. That is a problem. Now you will have to set the parameter before the clip and set it back again right after (since you can't use save/restore since it blows away the clip) How about the interaction of stroking and this parameter (if you follow the spec's wording for stroking)? This needs to change as well to match the new behavior. This is more a specification problem and no implementation problem. I agree. However, user agents didn't have to really think about this before but they will have to in the future. Making it part of the state will make it much more difficult to implement cleanly. How about ispointinpath? Will that follow the winding rule in the graphic state? It would depend on the fillRule that you set on the context. How about hit regions? How can you specify the winding there? This is a good point. But it depends if hit region will be implemented as specified. It's better to follow what almost every other graphics library has done: Add an EOFill and an EOClip. I volunteer to add it to Mozilla if it helps. That is not fully correct. Just Qt and Skia make it explicitly on the Path object (which is not necessarily depending on the fill operation itself). CG does not bundle EOfill with a path, instead you set it during painting. Which is partly as done by the specification, with the exception that it is not part of the graphic state, but also not part of the path logic. Core graphics has indeed no support for paths (just like the current canvas implementations) However, it does have 'CGContextEOClip' and 'CGContextEOFill' that works on the current path which is what I propose we should do. Cairo graphics has the fill rule as part of the graphic state IIRC. This discussion is a bit misplaced on webkit-dev. Could you continue it on the WHAT WG mailing list please? I agree. However, if people didn't follow that mailing list, they would think that everything is sorted out since Ian emailed this list to say that it is in the spec . I would just agree with Rik here, that we should wait a bit more time before implementing it in WebKit. Even if following the Firefox implementation and the needs of PDF.js is a good reason for implementing as suggested by the spec. If it's for PDF, then a graphic state variable is not the way to go since PDF does not have this either. Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Jan 4, 2013, at 7:28 PM, Rik Cabanier caban...@gmail.commailto:caban...@gmail.com wrote: On Fri, Jan 4, 2013 at 5:42 PM, Dirk Schulze dschu...@adobe.commailto:dschu...@adobe.com wrote: On Jan 4, 2013, at 5:24 PM, Rik Cabanier caban...@gmail.commailto:caban...@gmail.com wrote: On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson i...@hixie.chmailto:i...@hixie.ch wrote: On Fri, 4 Jan 2013, Rik Cabanier wrote: I think this feature was rushed in the spec. The specing is usually the first step. You can't rush to spec. :-) In this particular case, though, it was the third or fourth step. The discussion has been open since June 2011. It's not like people didn't have time to comment. It's been shipping in a browser for over a year. Any solution we come up with to the issues that were raised regarding Path will almost certainly be done in a way that builds on context.fillRule, not in a way that removes context.fillRule. I was not aware of that discussion. There are good reasons to make the fill rule part of the fill operation itself. It does not make sense in the graphic state. How about EOClip? That is a construct that is far more used than eofill. Will that get its own parameter too? It will use the same property, since there is no difference. That is why the name could be a bit misleading. windingRule would be a bit more independent of the fill operation. That is a problem. Now you will have to set the parameter before the clip and set it back again right after (since you can't use save/restore since it blows away the clip) I don't see the problem here. That is how canvas works currently. fill() and clip() use the currentPath. Seems to be more natural to use the property then. How about the interaction of stroking and this parameter (if you follow the spec's wording for stroking)? This needs to change as well to match the new behavior. This is more a specification problem and no implementation problem. I agree. However, user agents didn't have to really think about this before but they will have to in the future. Making it part of the state will make it much more difficult to implement cleanly. Not at all, as demonstrated with the patch. How about ispointinpath? Will that follow the winding rule in the graphic state? It would depend on the fillRule that you set on the context. How about hit regions? How can you specify the winding there? This is a good point. But it depends if hit region will be implemented as specified. It's better to follow what almost every other graphics library has done: Add an EOFill and an EOClip. I volunteer to add it to Mozilla if it helps. That is not fully correct. Just Qt and Skia make it explicitly on the Path object (which is not necessarily depending on the fill operation itself). CG does not bundle EOfill with a path, instead you set it during painting. Which is partly as done by the specification, with the exception that it is not part of the graphic state, but also not part of the path logic. Core graphics has indeed no support for paths (just like the current canvas implementations) However, it does have 'CGContextEOClip' and 'CGContextEOFill' that works on the current path which is what I propose we should do. No, because the path is already applied to the context. That makes the property so natural and easy to implement. Cairo graphics has the fill rule as part of the graphic state IIRC. This discussion is a bit misplaced on webkit-dev. Could you continue it on the WHAT WG mailing list please? I agree. However, if people didn't follow that mailing list, they would think that everything is sorted out since Ian emailed this list to say that it is in the spec . Right. I would just agree with Rik here, that we should wait a bit more time before implementing it in WebKit. Even if following the Firefox implementation and the needs of PDF.js is a good reason for implementing as suggested by the spec. If it's for PDF, then a graphic state variable is not the way to go since PDF does not have this either. PDF.js - the JavaScript library. Not PDF the standard. And the library uses it already according to previous posts. Greetings, Dirk Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Fri, Jan 4, 2013 at 8:04 PM, Dirk Schulze dschu...@adobe.com wrote: On Jan 4, 2013, at 7:28 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Jan 4, 2013 at 5:42 PM, Dirk Schulze dschu...@adobe.com wrote: On Jan 4, 2013, at 5:24 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Jan 2013, Rik Cabanier wrote: I think this feature was rushed in the spec. The specing is usually the first step. You can't rush to spec. :-) In this particular case, though, it was the third or fourth step. The discussion has been open since June 2011. It's not like people didn't have time to comment. It's been shipping in a browser for over a year. Any solution we come up with to the issues that were raised regarding Path will almost certainly be done in a way that builds on context.fillRule, not in a way that removes context.fillRule. I was not aware of that discussion. There are good reasons to make the fill rule part of the fill operation itself. It does not make sense in the graphic state. How about EOClip? That is a construct that is far more used than eofill. Will that get its own parameter too? It will use the same property, since there is no difference. That is why the name could be a bit misleading. windingRule would be a bit more independent of the fill operation. That is a problem. Now you will have to set the parameter before the clip and set it back again right after (since you can't use save/restore since it blows away the clip) I don't see the problem here. That is how canvas works currently. fill() and clip() use the currentPath. Seems to be more natural to use the property then. With the property, you will have to always be sure that it is set to the value you expect. So you either set it before every draw or clip, or you only set it before doing an eoclip or eofill and then set it back. How about the interaction of stroking and this parameter (if you follow the spec's wording for stroking)? This needs to change as well to match the new behavior. This is more a specification problem and no implementation problem. I agree. However, user agents didn't have to really think about this before but they will have to in the future. Making it part of the state will make it much more difficult to implement cleanly. Not at all, as demonstrated with the patch. in the *future*, when for example there is support for paths, this global flag will make it more difficult. (Paths will need to take winding into account if we want the regions to be useful) How about ispointinpath? Will that follow the winding rule in the graphic state? It would depend on the fillRule that you set on the context. How about hit regions? How can you specify the winding there? This is a good point. But it depends if hit region will be implemented as specified. It's better to follow what almost every other graphics library has done: Add an EOFill and an EOClip. I volunteer to add it to Mozilla if it helps. That is not fully correct. Just Qt and Skia make it explicitly on the Path object (which is not necessarily depending on the fill operation itself). CG does not bundle EOfill with a path, instead you set it during painting. Which is partly as done by the specification, with the exception that it is not part of the graphic state, but also not part of the path logic. Core graphics has indeed no support for paths (just like the current canvas implementations) However, it does have 'CGContextEOClip' and 'CGContextEOFill' that works on the current path which is what I propose we should do. No, because the path is already applied to the context. That makes the property so natural and easy to implement. yes, the current path is in the context, but not the winding rule. That is specified with 'CGContextEOClip' or 'CGContextEOFill'. To me, this makes eofill and eoclip a more natural implementation. Cairo graphics has the fill rule as part of the graphic state IIRC. This discussion is a bit misplaced on webkit-dev. Could you continue it on the WHAT WG mailing list please? I agree. However, if people didn't follow that mailing list, they would think that everything is sorted out since Ian emailed this list to say that it is in the spec . Right. I would just agree with Rik here, that we should wait a bit more time before implementing it in WebKit. Even if following the Firefox implementation and the needs of PDF.js is a good reason for implementing as suggested by the spec. If it's for PDF, then a graphic state variable is not the way to go since PDF does not have this either. PDF.js - the JavaScript library. Not PDF the standard. And the library uses it already according to previous posts. yes, I realize that. That library will be easier to implement if canvas has the same behavior as PDF.
