gmane.comp.mozilla.devel.layout

Re: WebPrintAPI Proposal

Robert O'Callahan — 2012-05-04T00:44:27

On Fri, May 4, 2012 at 7:36 AM, Julian Viereck <
julian.viereck< at >googlemail.com> wrote:


Your arguments are irrefutable.

Rob

Re: WebPrintAPI Proposal

Julian Viereck — 2012-05-03T19:36:52

Taking discussion from IRC with :roc offline:


Failing on one page is bad enough. Imagine the user starts the print job, goes to the printer and the printout looks correct at the first spot. But later he notice, something is missing that he depends on it.

Also, printing red crosses might be very expensive for the user and therefore he'd like to know if something went wrong.

As the abortion is programatic, the printing can get aborted, the developer notifies the user that something went wrong during printing and might give him the option to reprint but skip the failing page.

Roc, what's your feeling about the proposed `abort()` now?

Best,

Julian

Re: WebPrintAPI Proposal

Julian Viereck — 2012-05-01T20:06:54

The async version of the mozPrintCallback API is working for printing output (it still has very rough edges, but it "works").

However, things don't work correctly for print-preview: As I open print-preview, I see the calls on the canvas, that are done immediately when the mozPrintCallback is called. The drawings performed against the canvas context with some delay don't show up in preview. If I scroll the preview window, the repainted area of the canvas show the updated/right content. Also, if the print preview loses focus, the canvas shows the actual content.

It looks like the "redraw this (part of the) canvas, as something in it changed" doesn't work.

I tried to figure out what's going wrong here, but I know to little about the Gecko layout/redraw code/handling and what I should look for :/

Here is what I got so far:
* nsCanvasRenderingContext2D.mIsEntireFrameInvalid doesn't seem to get reset to false
* I've forced to ignore `mIsEntireFrameInvalid` and let the call to  `nsHTMLCanvasElement::InvalidateCanvasContent` happen. The `!GetPrimaryFrame()` evaluates to true and therefore the function returns early without telling the layer to update

 Can someone give me some pointers what to do here?

A way to get around this issue is to draw the nsPageFrame after all the canvas elements inside this page have finished the mozPrintCallback. Rendering the canvas progressive in print preview has the advantage to display other parts of the page (e.g. "normal" DOM content) to the user already and let him look at the drawings, while they build up.

Best,

Julian

Re: WebPrintAPI Proposal

fantasai — 2012-04-27T01:19:29

If div.foo is assigned a different 'page' value than its previous sibling,
it forces a page break. So the first page remains unaffected, and the
next page is 4cm x 4cm.

http://dev.w3.org/csswg/css3-page/#using-named-pages

~fantasai

Re: WebPrintAPI Proposal

Julian Viereck — 2012-04-26T18:10:22

Can someone give me pointers what writing the unit test for the mozPrintCallback should look like (very roughly what's expected to be tested)? Are there already some tests for printing that I could use as a "template"?

Best,

Julian

Re: WebPrintAPI Proposal

Robert O'Callahan — 2012-04-25T05:47:44

On Wed, Apr 25, 2012 at 9:31 AM, Julian Viereck <
julian.viereck< at >googlemail.com> wrote:



That sounds right.



Yes. (It is for print preview too.)



What Daniel said. I'm not sure how you should handle print-selection ---
probably just disable the callbacks and print whatever's already in the
canvases, or refactor print-selection so we don't do this loop here.

Rob

Re: WebPrintAPI Proposal

Daniel Holbert — 2012-04-24T22:20:14

AFAICT, that code only triggers multiple BeginPage calls if we're doing
Print Selection.

Print Selection is special.  Rather than explicitly paginating our
content into separate page frames, as we normally do, we instead render
the entire selected region onto one giant page frame, and then we paint
that onto multiple physical pages. (This mostly works, but it can cause
problems if we pick a bad spot to split[1].)

So -- when we're doing Print Selection, we end up only printing a single
(tall) page _frame_, so we only need one call to PrintNextPage(). But we
print that frame onto multiple *physical* pages, so we end up calling
BeginPage multiple times.

(I'm not sure about your other questions, offhand.)

~Daniel

[1] e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=240625

Re: WebPrintAPI Proposal

Julian Viereck — 2012-04-24T21:31:37

I'm pretty close to have `async` support done for the mozPrintCallback, but I'm stuck with a problem that I don't know how to solve best.

Here is some very basic background to understand my problem:

- I've implemented a new function `nsSimplePageSequenceFrame::PrePrintNextPage()` that is called from the nsPrintEngine/nsPagePrintTimer to deter if the current page is ready for printing. If the function returns `true`, nsSimplePageSequenceFrame::PrintNextPage() is executed that does the actual printing to the page.
- PrePrintNextPage does the canvas-surface-replacement to replace the pixel based surface by a vector one that is used for printing. If there are no canvas with a mozPrintCallback or the page doesn't get printed, it returns true. Otherwise, it waits until on all canvas with a mozPrintCallback the `done()` function is called.

[I have the two current function PrePrintNextPage() and PrintNextPage() here: https://gist.github.com/2483955#L611]

The problem is now in the "canvas-surface-replacement": The "renderingSurface->CreateSimilarSurface()" function call only returns  a vector-based surface iff "dc->BeginPage()" was called at least once before. However, for the first page, this is not the case (as "PrePrintNextPage()" is called before "PrintNextPage()", which does the call to dc->BeginPage()).

An easy solution might be to "move all the code from the beginning of `PrintNextPage` until the dc->BeginPage() into the "PrePrintNextPage()" function. Then, before a similar surface is created, a dc->BeginPage() call already happened. To do this, I need some more clarification on this code:

    http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsSimplePageSequence.cpp#620

* can PresContext()->IsRootPaginatedDocument() be false at any time? The `PrintNextPage()` function is only called for printing to paper - it's not called for preview. Therefore, the PresContext is always a paginatedDocument?
* the function might call `dc->BeginPage()` multiple times. Shouldn't this function add only one page to the output? Is this a bug or a feature?
* was this code in "PrintNextPage()" used once for rendering the preview window output as well (which is longer the case if I read the code right)? Are the two points I've listed above left over from sharing the same function and can be removed now?

 Best,

Julian

Industrial Automation Training and Placements in Coimbatore

logeswari raja — 2012-04-24T09:00:50

http://www.facebook.com/pages/Hindustan-Technologies-Private-Limited/318300758211251

Re: Validating css property values

L. David Baron — 2012-04-20T14:00:49

We could add something, but it would basically just do the same
thing under the hood -- toggle off CSS error reporting -- which
essentially means that I don't think there's a point doing it unless
the pref-toggling is a performance problem.


I can't think of any reasonably way to do this; we don't have the
structure for generating this sort of thing.

-David

Validating css property values

Mike Ratcliffe — 2012-04-20T11:12:40

As part of our css devtools we need a way to check that a css property value is valid. This is used to validate the value onkeyup. Our current solution is to call the following method on each keypress:

  function validate(aValue)
  {
    let name = this.prop.name;
    let value = typeof aValue == "undefined" ? this.prop.value : aValue;
    let style = this.doc.createElementNS(HTML_NS, "div").style;

    style.setProperty(name, value, null);

    return !!style.getPropertyValue(name);
   },

The problem with this solution is that it spews css error messages for invalid property values, but we could work around this with:

  let prefVal = getPref("layout.css.report_errors");
  setPref("layout.css.report_errors", false);
  try {
    style.setProperty(name, value, null);
  } finally {
    setPref("layout.css.report_errors, prefVal");
  }

It occurs to me that we are also adding autocomplete to the properties, so can any of you guys think of:
1. A better way to validate css property values.
2. A way to get a list of possible property values for a given css property (this could be used for autocomplete and validation).
3. A better way to do both 1 and 2 ;o)

~Mike Ratcliffe

Wiki Wednesday (CSS) - April 19, 2012

Sheppy — 2012-04-19T12:17:03

Here are today's Wiki Wednesday articles! If you know about these
topics, please try to find a few minutes to look over these articles
that are marked as needing technical intervention and see if you can
fix them up. You can do so either by logging into the wiki and editing
the articles directly, or by emailing your notes, sample code, or
feedback to mdnwiki< at >mozilla.org.

Contributors to Wiki Wednesday will get recognition in the next Wiki
Wednesday announcement. Thanks in advance for your help!

1) inherit ( http://mzl.la/HF2vAM )
2) background-clip ( http://mzl.la/HJGvSb )
3) clip-path ( http://mzl.la/eGdxye )

Re: WebPrintAPI Proposal

2012-04-17T21:11:08

One part of the spec that might need to get implemented for PDF.JS is the ability to specify the size of individual pages. If I get that right from the spec, this can be done like this:

    < at >page narrow { size: 4cm 4cm }
    div.foo { page: narrow }

Can you please help me, what the expected behavior is in the following case:

Assume the default page size is A4 and a div matching "div.foo" is at the very bottom of the first printed page. As it has a `page` property defined, the `< at >page narrow` properties get applied to the page the "div.foo" is on. But the page-size required the A4 page to shrink. As a consequence of the shrink process, the "div.foo" element is no longer on the same page as before, as it was at the very bottom and the page got smaller. In a consequence, the page that now contains the "div.foo" should get the narrow-page-size applied. But as the "div.foo" is no longer on the first page, the "< at >page narrow" doesn't apply to the first page anymore, and it size should be A4 again. But then the "div.foo" is on the first page again, the "< at >page narrow" get applied and ...

Do you see the endless loop? I haven't read the entire spec, but from what I read the behavior in this case is not clear to me. 

Also, what should happen if there are two divs on the page, both referring to "< at >page" definitions but have different page-sizes applied. Should the first div's page-size win over the second?

Best,

Julian

Re: WebPrintAPI Proposal

Robert O'Callahan — 2012-04-17T12:35:37


Good thought, but I think it's fine for it to be the canvas in the page
DOM. If that canvas has been removed from the document, that's OK.

* The current implementation sets the size of the rendering context to the

For high quality, we need an extended version of get/putImageData that can
work at higher resolution.

To solve this, should the canvas context size be at least the size of the


I don't think we need to do that.

Rob

Re: WebPrintAPI Proposal

2012-04-16T21:00:46

While thinking about what a proposal to WHATWG about the printCallback-API should look like, I've came across the following edgecases.

* the context passed to the mozPrintCallback function has a `canvas` property. I think this `canvas` property should not exist on the mozPrintCallback passed in `ctx` and should return `undefined.

What should this canvas be? If it's the canvas of the print-document, performing operations like `appendChild` to the HTML tree, that gets printed, can cause issues, as it's assumed that this tree is static and can't change. On the other side, the `canvas` might refer to the canvas in the DOM, but this canvas was removed in the meantime (= during the time frame the printing starts and the callback is called) maybe .

Instead, I propose the second argument passed to the callback should contain the `width`, `height`, `id` and `name` of the canvas as at the beginning of the printing process.

The usage of the mozPrintCallback might then look like this:

  canvas.mozPrintCallback = function(ctx, obj) {
    console.log(obj.width, obj.height, obj.id, obj.name);
    // ...
  }

* The current implementation sets the size of the rendering context to the size of the actual canvas on the screen if in preview. The canvas context is then scaled, such that the behavior of the canvas context "feels" the same in normal DOM usage. While this works, this might cause problems when using `getImageData` on the canvas.

Imagine the print preview has a zoom set to 10%. If the canvas has normally a width of 100px, it might now only have 10px in preview. The internal used context of the canvas is then only 10px in width, but if the user requests imageData with width 50px, this gets mapped down to 5px (due to internal scaling). But then the 5px gets scaled by factor 10 to get the 50px of the imageData size. As a result, the imageData the user gets might not be of the quality it is used to be.

To solve this, should the canvas context size be at least the size of the canvas.width/canvas.height as specified in the DOM? If the size is larger, there might still be some loose in quality, as the data needs to be down-scaled for the requested imageData (imagine the canvas has a width of 100px in the DOM and 200px in preview - then the canvas context has a width of 200px as well and the width is scaled by a factor of 2 when a getImageData requiest is done). But I don't expect the image quality loose too be as bad as when the canvas context gets very tight compared to the expected canvas size.

Does these changes make sense?

Best,

Julian

Re: Please confirm if a bug

Gus Richter — 2012-04-15T20:30:49

OK, I determined the problem. please ignore.
Placing the divs on the same line in the markup removes the 8px problem.

Please confirm if a bug

Gus Richter — 2012-04-14T17:22:25

Please look at:
 
<http://www3.bell.net/monique.richter/ThreeImagesSpacedEvenly%20-%204%20areas%20now%20-%20divs.htm>

and confirm if a bug and if so, if it is known.

HostMath - Online LaTeX formula editor and math equation editor

Jack — 2012-04-12T12:57:31


HostMath is a powerful interactive mathematical expressions editor. It
uses WYSIWYG-style editing and allows creating mathematical equations
through simple point-and-click techniques.

1. Many pre-defined Templates and Symbols in well-organized palettes
that cover Mathematics, Physics, Electronics, and many other higher
educations
2. Fine adjustment for Template shapes, gaps, and thicknesses with
visual interface
3. Multiple Undo and Redo
4. Can generate equations as MathML. MathML will allow you to copy and
paste math into many applications that understand MathML.

URL: http://www.hostmath.com/

Re: WebPrintAPI Proposal

Robert O'Callahan — 2012-04-01T22:26:07

On Sun, Apr 1, 2012 at 6:16 AM, Julian Viereck <
julian.viereck< at >googlemail.com> wrote:


Hmm. Can you explain this a bit more?



We probably need to set it somewhere.



I see. What sort of image data computation are we talking about? Probably
the proposed getImageData extensions, or some other API to get the actual
DPI of the canvas, would cover this.

I've played around with some CSS units (code in [1], resulting PDF in [2]).

I see what you mean. The problem is that setting the CSS width and height
of the canvas scales "canvas units", and the font size you specify is in
canvas units.

Changing this would make printing behave differently from normal drawing,
so we probably shouldn't change anything by default.

I looked into this today. I moved the code to swap the surface and call the

We shouldn't switch the canvas type here, that's just wasteful (since
internally we'd render to a PDF surface or something and then render that
to a raster surface). Print preview should use the same canvas type as
normal screen drawing.

What we really need to do here is render to a higher-resolution backing
surface of the screen type. That's going to require a bit more canvas work.

Rob

Re: WebPrintAPI Proposal

Julian Viereck — 2012-03-31T18:16:45

Thanks :)


The second argument might look like this:

sndArgument = {
  DPI: 200,
  preview: false
};

It's intended to expose more print related information to the user.



cairo_surface_get_fallback_resolution requires a cairo surface. Therefore I've added a new `GetFallbackResolution` on the gfxASurface class.

Calling this function always return 300 by 300 pixels per inch. That's independent of the print quality I set on my printer or wether I choose "Save as PDF". The cairo documentation states

    "This function returns the previous fallback resolution set by cairo_surface_set_fallback_resolution(), or default fallback resolution if never set."

Therefore I'm wondering if this is really related to the actual DPI of the printer or just picks up some default value.



Imagine you print a canvas that contains some computed image data. If you know the actual size of the canvas on the paper and the DPI resolution, one can compute what dimension the image data has to be in order to look good on the printout (e.g. if you don't compute a high enough resolution, the user will see pixels in the printout).

Even in the case that the DPI of the printer might not be determinable, using 300DPI as the default value and multiply it by the size would still give a good guess what the image data size has to be.


Using "position: relative" works like expected and scales the canvas to fit on a page each.

I've played around with some CSS units (code in [1], resulting PDF in [2]). The "mm"-size used for the ctx.font has nothing to do with the actual printout size. This feels consistent to me and therefore right, as it renders to the same size/way the DOM canvas does, but it can confuse people that expect to get really 5mm on the printout. 

What's the way it should be?

Julian

[1]: https://gist.github.com/2267257 
[2]: http://n.ethz.ch/~jviereck/drop/Preview_print_test_page.pdf

Re: Synchronizing test with W3C

L. David Baron — 2012-03-30T07:25:10

Agreed.  It makes more sense to keep tests near the code the test.

-David