I have following printing code:
void Print(QPrinter *printer)
{
QPainter q(printer);
q.setRenderHint(QPainter::HighQualityAntialiasing, true);
q.setPen(QPen(QColor("red")));
q.drawRect(printer->pageRect());
q.drawLine(printer->pageRect().topRight(), printer->pageRect().bottomLeft());
q.setPen(QPen(QColor("blue")));
q.drawRect(printer->paperRect());
q.drawLine(printer->paperRect().topRight(), printer->paperRect().bottomLeft());
}
The result is different with QPrintPreviewDialog, rendered PDF, output to printers (HP LaserJet, PdfFactory, PdfCreator). Most of time the resulting rectangle is out of paper. What to do so the output is similar to all printers?
This really was asked some time ago, but I took the code from above and it cost me some hours to figure out, what's wrong with it.
First, looking at the Qt source code, I could not find any place which assumes a 5% margin.
Qt reads back the margins correctly from Windows XP and you can completely trust the page margins (Qt 4.5.3 with Windows XP).
The code above contains two issues: for printing a paperrect, the fullPage option must be set. Then the paperRect is printed at least on the preview correctly. Of course not on a real printer, as it is outside the pageRect.
Generally, printing the paperRect makes no sense, as, if printed correctly, it lies exactly on the paper border.
The second major issue stems from printing pageRect without correcting the origin.
If fullPage is disabled (default), then the pageRect origin lies at the paperRect origin thus includes the margins.
But printing starts at QPoint(leftMargin,topMargin), so the margin is added twice.
To fix the issue, pageRect.moveTo(0,0) needs to be called and then the pageRect prints nicely where it belongs.
That different printers show different results comes from different device margins. Only devices with 0-margin will work with the original code.
The Qt code I reviewed assumes 5% of paper as it's margin. Nobody trusts on correct paper margins.
Related
This is a workflow related question. I'm trying out working only (or mostly) in the Rmarkdown source window with the options set to "Chunk output inline". So with R open, there is just one big window -The environment, Console and File windows being minimized.
My question: Is there some option to change the number of columns displayed? I want to increase the numbers of columns visible without scrolling (see screenshot below), and since there is enough space I think it should be possible to display more of them.
Many thanks!
Solution: There is an option. Just add cols.print = 12 (or whatever number you want) to global options.
Also, people might find this 'manual' on markdown useful: https://bookdown.org/yihui/rmarkdown/html-document.html#paged-printing
I render the exact same R bookdown source, but get slightly different results depending on the operating system. This only regards the wrapping of the output width of code chunks when rendering with pandoc to HTML.
If the output is rather large like this
on Windows 10 it adds a horizontal scroll bar, when looking at it on smaller screens.
Running the same code on Ubuntu 20.04 gives me a different result
I checked the output message of bookdown::render_book("index.Rmd", "bookdown::gitbook") and it's the exact same for both operating systems. The pandoc version is the same, too (2.11.4).
Any idea is highly appreaciated.
To inspect options("width") was the right hint from #thothal. I explicitly set the tibble.width but not the width globally.
The lines will break without a horizontal scroll bar, if tibble.width > width. After updating my packages and RStudio I saw the same behavior on both operating systems. Not quiet sure though, what caused the difference in the first place. Maybe something changed for the tibble.width option internally. Or the default width depends on the OS or screen width of the device where it's run (unlikely).
To summarise: The tibble.width has to be equal or smaller than the global width to avoid that ugly line break. It's best to set both explicitly.
When Octave draws a plot, I would like it to set that to be the active window automatically, so that it becomes visible and I don't have to click back and forth between windows to see if the code and plot have finished. Is this possible? Since it would require reaching outside of Octave and controlling the OS, I'm not sure; it depends on whether or not that capability is part of Octave but I haven't found a reference for it yet.
I can always tell Octave to close the figure before opening a new one in the code, but that could prevent me from drawing multiple plots on the same axes, and it would require me to code that command in every time. It would be nice if there were a direct way just to bring the plot to be visible and take dominance over other windows.
EDIT: Somehow, although I noted that Octave would be required to control the OS to achieve this, I completely forgot to mention what that was... I'm running Windows 10 with the default window manager; I believe that would be the Desktop Window Manager.
When you plot something on a figure (whether you specify the figure you're plotting to within the plot command explicitly or simply let it plot into the currently active figure implicitly), this does not automatically raise the figure window to the forefront.
To do so, call the figure again using the figure function, along with the handle that you want to raise.
Alternatively, if you're sure that the figure you want to raise is the currently active one, you can simply use the shg command (which is effectively equivalent to figure(gcf))
E.g.
Fig1 = figure; % (or figure(1) if you want to be explicit)
Fig2 = figure; % (or figure(2) if you want to be explicit)
figure(Fig1); plot(1:10); % raise Fig1 to the forefront, and plot.
PS: Note that there was a bug affecting this behaviour until recently (coincidentally submitted by yours truly :p See https://savannah.gnu.org/bugs/?45943 ). This is fixed in the latest version of octave though (i.e. 5.1.0)
Background: I've written R code to create data summary tables that are exported into Excel templates using openxlsx. The tables vary in size and content with each new dataset, often spanning many pages. The data rows are all the same height, but each page also has a footnote at the bottom, which can vary in height. I have openxlsx code to adjust the height of the footnote row, which must be large enough to fit the text but small enough so the row doesn't get pushed onto the next page. The code is proprietary and I can't post it, but here's an example*:
setRowHeights(
wb,
sheet=excel.tab,
rows=c(rowlist$lastrow.excel),
heights=footnote.height2
)
*All of the inputs other than "wb" are dynamically assigned elsewhere in the program.
Problem: As far as I can tell, openxlsx only allows you to specify row heights in Excel row height units, as opposed to a standard measurement like inches. This seems to result in wildly different row heights (both in inches and in terms of fitting on the same exact page template) depending on the specific computer monitor I'm working on. For example, code that works fine when my laptop is hooked up to my work station will produce giant rows when I'm working on the laptop's monitor. I previously ran into the same issue with the XLConnect package, which makes me think this is a general issue with how R interacts with Excel as opposed to a unique limitation of openxlsx.
I noticed that other openxlsx functions allow you to input the screen's DPI (including vertical and horizontal DPI in some cases) for scaling, which led me to conclude that differences in DPI might account for the scaling discrepancies across screens. Unfortunately, I haven't found a way to import the DPI of a specific screen into R in order to adjust the setRowHeights input to work with that screen.
I've spent countless hours researching and troubleshooting this problem with no luck. Any advice would be greatly appreciated!
Under Atom 1.23.3 x64, I can see some visual parasites (see picture below), like vertical blue lines. It happens whatever the file format (.py, .tex, .txt...).
I'm under linux Debian Buster/Sid.
Edit : this "thing" apparition seems to be randomness and purely visual, i.e., it's impossible to select and inspect it. It lies in between two caracters. It will move if I zoom in or out, but always be somewhere, as noise.