Print Preview triggers xs breakpoint

[tmburnell]

Bug, feature request, or proposal:

Using chrome: while using either fxHide fxShow.xs or fxShow fxHide.xs the xs breakpoint is triggered when printing. This does not seem to be the behavior on firefox (I am on a mac so have not tested IE).

What is the expected behavior?

A piece of paper is big enough that it should not be triggering the xs breakpoint
Also it should be consistent across browsers

What are the steps to reproduce?

Providing a StackBlitz (or similar) is the best way to get the team to see your issue.

• https://stackblitz.com/edit/angular-flex-layout-printpreview?embed=1&file=main.ts

What is the use-case or motivation for changing an existing behavior?

The existing behavior seems to be incorrect and probably overlooked.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular: 5.2.0
flex-layout: 2.0.0-beta.12

[CaerusKaru]

This is not a bug, so much as a possible opportunity to add a feature.

By default, the media query engine is only tied to the screen. You can augment this yourself by providing custom breakpoints (or just mapping over the defaults) and including the following query:

(max-width: 575px) becomes print, screen and (max-width: 575px)

The possible avenue for feature enhancement is adding a token that does this for the user. Something like FLEX_BREAKPOINT_PRINT. I'll discuss this with @ThomasBurleson offline, but in the meantime, the workaround is providing your own breakpoints and augment them with the print property.

[tmburnell]

I am not sure I 100% follow what you are saying...
I did update the stackblitz to make it a little more clear (and also note I have a print button to make printing easier).

So my points of consern:

1. Why specifically does print preview on chrome trigger the 575 breakpoint ... when the rest of the content looks like it is well above the 575 breakpoint (my example may not demonstrate comparison well)
2. For Firefox I have determined it prints however the page was when print was selected (which seems incorrect ... however more correct than chrome).
3. I could be wrong but shouldn't you be able to relate an 8 1/2'' / 11'' pager to an existing breakpoint (like medium)?

[CaerusKaru]

The default for @media queries is just screen, which means the view you see in the browser. In order to apply the breakpoints in print mode as well, the media query that's registered needs to the include the print key.

See here for reference

[tmburnell]

Since You say this is not a bug, can you help me determine how I can control the print?
In the example I provided; How do I print on any scale other than extra small, so that the div containing this will displays:

ALWAYS SHOW ME UNLESS I AM SMALL 
(SHOULD PRINT ME)

[tmburnell]

Based on the following link: https://github.com/angular/flex-layout/wiki/BreakPoints
I have tried applying this and create the below stackblitz: https://stackblitz.com/edit/custom-print-directives

It has a few issues still:

1. When large xs is still firing and overwritting the print
2. after the close of the print window it does not retrigger the breakpoint to set it back (on xtra small)
3. As of Media observable is not triggering in Firefox print preview #615 you can see some of the same issues both firefox and safari

[jeremyrans]

I ran in to the same issue where my print styles seemed to be using my lt-sm breakpoints. It seems like the pixel width of a 8.5" printed page falls in that <599px range. This can be demonstrated with the following example which uses the lt-sm breakpoint when printing in portrait mode but not in landscape mode:

Portrait:

Landscape:

After a few hours of experimenting, I ended up augmenting all of the default breakpoint media queries to be prefixed with only screen and. The result being that my print styles always use the default values, which is what I wanted. I also looked at adding an explicit print breakpoint/directive which would have worked, but I didn't want to pollute my source with explicit print rules when just using the defaults would work.

Plunkr: https://plnkr.co/edit/90So8jVmOBkEcs2Z6UGD?p=preview

Edit: in doing some research, it sounds like the browser may use a DPI of 72 when printing, which makes sense given the above example (8.5" with 0.5" margin on either side gives 7.5" * 72dpi == 540px)

[yogeshgadge]

With FlexLayout 7.0.0-beta.19 the following things just works fine on Chrome (70+)).

@NgModule({
   imports: []
   providers: [    {
      provide: BREAKPOINTS,
      useValue: DEFAULT_BREAKPOINTS
    }],
})
export class AppModule {}

So what in the world an explicit custom breakpoints providing (the same DEFAULT_BREAKPOINTS) makes it work/. Question is why ?

[tmburnell]

I updated my stackblitz to the latest everything: https://stackblitz.com/edit/angular-flex-layout-printpreview-fmbgnk?file=app/app.component.ts

I see no impact with the change that @yogeshgadge notes, however with the latest angular and flex it does have a different interaction. Chrome now operates like firefox did, and print preview will print what ever mode it was when print was triggered.

I would still would expect it to be able to print at normal or have a setting like #869. because i would want it to print the same no matter if you are printing from a phone or a computer.

[CaerusKaru]

@tmburnell Does that mean this can be folded into #869? Otherwise, can you give me an idea of how the implementation would work?

[tmburnell]

In this example: https://stackblitz.com/edit/angular-flex-layout-printpreview-fmbgnk?file=app/app.component.ts

When you print it should always show the red and blue sections. I made the yellow section to replace the blue to be mobile (or small resolution), but when printing i want it to still be the blue section.

So i am fine with either option as long as there is a solution:

• Always print medium breakpoint
• Have a print breakpoint that will be used for printing (when i opened this i tried custom breakpoints but it still used the small)

[CaerusKaru]

How about this:

• When provided as a config, Flex Layout will listen for print events on the DOM
• When a print event is received, Flex Layout will activate a provided breakpoint (even a default breakpoint), and give it a priority high enough to override everything else
• When the print event ends, the styles will be restored to previous

[tmburnell]

Sounds good to me

[CaerusKaru]

I'm very excited to say that the fix for this, #954, is nearing completion. Thanks to Thomas' excellent work on this, the API is really simple to use, and we'd love some feedback before we make this change to the library.

First: by default, print layouts will fallback on the currently activated breakpoints. That is, they will no longer deactivate on print by default.

Second: you can specify a specific breakpoint alias that will be your "primary print" alias (e.g. md, xs, etc). You can also specify more than one in case you want a fallback mechanism.

Third: we've added support for fxShow.print and fxHide.print natively as it's very critical behavior to support

Let us know what you think of these changes, and feel free to check out the PR (though don't necessarily add comments for small things – it's still being polished!).

[epelc]

@CaerusKaru @ThomasBurleson Can you clarify what the lack of BeforePrint support means? https://github.com/angular/flex-layout/blob/master/src/lib/core/media-marshaller/print-hook.ts#L133-L134

ie can I make a PR to add this or is there some technical reason you had to use mediaQuery activations instead? I hope to work on integrating beforeprint support to fix the layout switch rendering issues with printing.

OnBeforePrint()

• is not supported; so 'print' mediaQuery activations must be used.

I've tested these on beta.24+angular 8 and am still seeing racy layout switch rendering issues with printing(likely due to media query observables being async and chrome+other browsers not waiting for rendering changes to settle). I saw this before in beta.23 and put off upgrading due to this and other reasons but am ready to go now besides for this blocking me.

PS The PrintHook service and other changes are excellent and fixed a lot of other issues besides this! Thank you

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}