I've got Libreoffice Calc per the following:
Version: 5.1.6.2
Build ID: 1:5.1.6~rc2-0ubuntu1~xenial3
CPU Threads: 8; OS Version: Linux 4.13; UI Render: default;
Locale: en-US (en_US.UTF-8); Calc: group
I select FORMAT -> PAGE -> LANDSCAPE.
Print preview looks normal (landscape), and the sheet prints landscape.
I select FORMAT -> PAGE -> PORTRAIT.
Print preview looks normal (portrait).
However, upon selecting actual PRINT command, the thumbnail image in the dialog shows the page in landscape orientation, with the print material half-size, and vertically oriented.
If I copy-paste the spreadsheet into a new workbook, this behavior is not replicated.
I suspect that there's some setting somewhere that I have inadvertently tripped, but now cannot find.
Anyone have an idea what it could be?
Thanks!
It looks like it was a bug that has been fixed.
I downloaded LibreOffice 6.0.3.2, and portrait printing now just works!
Related
Since Android 11 the correct way of displaying a fully immersive fragment is by hiding and showing StatusBar and NavigationBars via the following code which fully supports all devices with a camera notch, at any API level. Note the WindowCompat version replaces the framework version, so you don’t need to check for a particular API level as you did when using the framework version.
Hide
WindowCompat.SetDecorFitsSystemWindows(Activity.Window, false);
WindowInsetsControllerCompat windowInsetsControllerCompat = WindowCompat.GetInsetsController(Activity.Window, Activity.Window.DecorView);
windowInsetsControllerCompat.SystemBarsBehavior = WindowInsetsControllerCompat.BehaviorShowTransientBarsBySwipe;
windowInsetsControllerCompat.Hide(WindowInsetsCompat.Type.StatusBars() | WindowInsetsCompat.Type.NavigationBars());
Show
WindowCompat.SetDecorFitsSystemWindows(Activity.Window, true);
WindowInsetsControllerCompat windowInsetsControllerCompat = WindowCompat.GetInsetsController(Activity.Window, Activity.Window.DecorView);
windowInsetsControllerCompat.Show(WindowInsetsCompat.Type.StatusBars() | WindowInsetsCompat.Type.NavigationBars());
This eliminated the overly complex, very poorly documented and potentially error-prone code like below, which was used prior to Android 11.
Window.DecorView.SystemUiVisibility = (StatusBarVisibility) (SystemUiFlags.Fullscreen |
SystemUiFlags.HideNavigation |
SystemUiFlags.Immersive |
SystemUiFlags.ImmersiveSticky |
SystemUiFlags.LayoutHideNavigation |
SystemUiFlags.LayoutStable |
SystemUiFlags.LowProfile);
I was attempting to provide a choice of either displaying all fragments fully immersive or allowing some fragments to display as “letterboxed” i.e. not allowing the window to render into the DisplayCutout area. So my existing preference choice Devices with Notches/Cutouts allow full screen display would have to change to support multiple choice.
The problem I hit was that code I had used (like the WindowCompat code above since Android 11) was failing to display the fragment fullscreen when first launched. When it opened for the first time the window would attempt to go full screen, but only the NavigationBar would be removed. The StatusBar area was left as a black rectangle. You could see the animation of the time on the left and the icons on the right side of the StatusBar disappearing, (statusBar contents removed) but the window didn’t render into the StatusBar area. Immediately when rotated, the fragment became full screen and when rotated back to Portrait it corrected itself and was full screen again.
So in frustration, I went hunting on StackOverFlow looking for a solution but everything I found suggested that my ImmersiveFragment class was coded correctly. Then because this was my first attempt at using Material 3, I then started to suspect Material3, so I went backwards to my NavigationGraph6 project (Material2) and after much testing, I was able to reproduce the same problem, which eliminated Material3.
More searching on StackOverflow and I came across a Kotlin post that was the same as all the others, except that it had the following line – equivalent to this C# line.
Activity.Window.AddFlags(WindowManagerFlags.LayoutNoLimits)
So I added that line before the WindowCompat.SetDecorFitsSystemWindows(Activity.Window, false) in the HideSystemUi() and then cleared the flags before the WindowCompat.SetDecorFitsSystemWindows(Activity.Window, true) line in the ShowSystemUi with
Activity.Window.ClearFlags(WindowManagerFlags.LayoutNoLimits)
and immediately it worked.
So my question is why is this required and has anyone come across the same problem with immersive fragments?
Definition of LayoutNoLimits – Allow window to extend outside of the screen ???.
Does anyone have a clue what this definition actually means?
To test the code (comment out the new lines in ImmersiveFragment.cs). You can find the project NavigationGraph7 at https://github.com/gmck/NavigationGraph7. The immersiveFragment is the RaceResultsFragment (inherits from ImmersiveFragment) accessed by the BottomNavigationBar on the SlideShowFragment.
I referred to the official doc both Android and Microsoft too. As you said that: "Allow window to extend outside of the screen". There are few official definitions of it...
You can check Can I set FLAG_LAYOUT_NO_LIMITS only for status bar?, it talks about usage of LayoutNoLimit. Wish it could be helpful to you.
I'm following the exact steps from this video (from 7:49 onwards): http://youtu.be/IwSTXY0awng?t=7m49s
The UIButton I'm adding to my view when changing the size class to, for example, portrait iPhone, always shows up. Note: only acts this way in extension mode (building a custom keyboard for example). When using a storyboard/view controller/app (exactly like the video), it works as expected.
Is this a bug or expected behaviour? Any work arounds?
I'm using flash CC to create an app for iPhone5.
In flash CC I start a new air for iOS file. I get a stage of 640x960. The stage is empty and there's no code. I publish, check it out on the iPhone and I get margins on the top and bottom. 1 cm each. It simply won't cover the whole screen.
I tick the full screen box in the settings -> still get the margins.
I add: stage.displayState = StageDisplayState.FULL_SCREEN; -> still get the margings.
I change the stage's size to various sizes -> all the same.
What am I missing? how do I make these margins disappear?
(I just want to see my empty stage covering the whole iPhone5's screen)
after many searches I found the answer to my problem here:
http://blogs.adobe.com/airodynamics/2012/11/07/deploying-air-apps-on-iphone-5/
I have rdlc file report (standtart A4, Landscape), that has
<PageHeight>21cm</PageHeight>
<PageWidth>29.7cm</PageWidth>
Problem is, when i'm trying to print (in docx, Word 2010 and 2013) that one of the test printers doesn't understand page format - in "Print preview" window, page size = "Custom page Size 11.69x 8.27", "Landscape Orientation". But document in preview mode is croped from sides. If i select page format "A4" or try to play with margins preview normalizes.
If i select diferent printer everything is well.
If i try generating report in pdf also everything is well.
Is this problem with my rdlc, printer or Print preview window? How to solve it? (so that customer won't need to select page format everytime)
Update
I opened up my docx as xml, and found that landscape tag was missing w:orient="landscape". If i add it - it works well. Now problem, how to do it programaticly? (ReportViewer.WebForms are user here).
I always used these settings and never had problems:
<PageHeight>21cm</PageHeight>
<PageWidth>29.7cm</PageWidth>
<LeftMargin>1.3cm</LeftMargin>
<RightMargin>1.3cm</RightMargin>
<TopMargin>1.5cm</TopMargin>
<BottomMargin>1.5cm</BottomMargin>
Maybe you have to set different left/right margins but probably is a specific printer problem.
So what i did, was workaround but it worked.
Using DocumentFormat.OpenXml i manually added document layout.
I am using iOS 4.3 and Apple's suggested method for printing a PDF, which is to set the shared UIPrintInteractionController's printingItem property to an NSData object containing PDF data. It's very easy, which is great, but I've found that when printing a PDF via this method, the content starts 4mm lower on the page than if I print via Preview.app on my Mac. As I am printing to pre-cut labels, precise positioning is important.
It appears that somewhere in the process, a (blank) header is being added to the page, which is causing the content to shift down the page. The resulting horizontal margins are the same on both iOS and Mac OS X so I suspect it really is a header, and not an all-around margin.
I have checked the following:
Is the printer adding the header? No, because the same results can be seen when printing to the Printer Simulator.
Is the iPad using a different paper size to the Mac? I have used the delegate method to ensure that the UIPrintPaper is the same for both.
Can I edit headerHeight for the UIPrintPageRenderer? No, because a renderer is not created when setting a printing item directly.
My workaround is to make the PDF generator (the server) create the PDF content 4mm higher up than it ought to be, but this breaks printing from Mac OS.
Out of ideas now! Thanks for any assistance.
You should check Apple's sample code PrintWebView. I believe the problem your having is because of the hardware margins. See SIMPLE_LAYOUT constant in PrintWebView sample to learn more. Hope this helps.