Problems:
I am printing custom size scenes, the printing must work on a variety of printers, standard or with custom sizes, or roll-fed (particularly this). Some of the custom printers are edge-to-edge.
The user-defined canvas may or may not match the printer paper size.... If the image is smaller than the paper, some printers will center it, others (like HP) print it on top left.
On some printers I can set "Custom" paper, others do not support it.
If the printer has minimum margins, some printers seem to clip, others to render from the top-left margin, and ma or may not clip on image size.
I would like to handle the clipping and margins myself and send to the printer the image as it should fit on "page".
m_printer->setPaperSize(QPrinter::Custom); //gives
QPrinter::setPaperSize: Illegal paper size 30
Assuming that the following works,
m_printer->setPaperSize(canvasRectangle.size(), QPrinter::Point);
getting the marked paper size in cups still returns the default marked in the ppd (Letter, w4h4, ...) (though I can print or cut that size)
What I need:
I need to find, for the (selected/custom) paper/page, the minimum margins.
I thought I could get the margins by just asking for them
qreal left, right, top, bottom;
m_printer->getPageMargins(&left, &top, &right, &bottom, QPrinter::Point);
qDebug() << left << right << top << bottom;
But regardless of printer (I tried HP, PDF and a custom edge-to-edge printer) I got 10 10 10 10.
I thought I would set them to 0 first... I got back 0. (but printing still used some tiny margins, which it either clipped or moved over depending on device, except for the edge-to-edge printers - so while I got no error setting margins to 0 when 0 is impossible, QPrinter told me it set margin to 0 successfully.)
Right now I am trying to make this work in Linux, using cups (and Qt 4.8) - I looked in the ppd of the various printers, but what I see, as ImageableArea for different provided sizes, is that each size has different margins - so that defies the minimum margins idea.
I imagined that the minimum margins (for maximum printable area) should not depend on the paper chosen, but on the printer geometry.
I considered getting the cups ppd option values for ImageableArea - but getting it for the "default" paper size doesn't seem useful if I am not using that paper size - and for custom paper size, there is a range so I don't know what I can get from it.
Also - I can't even seem able to get the cups option for ImageableArea:
const cups_dest_t* pDest = &m_pPrinters[iPrinterNumber];
for (int i = 0; i < pDest->num_options; ++i)
if (strcmp(pDest->options[i].name, pName) == 0)
// I can show options like "PageSize", "PageRegion" but not "ImageableArea"
I am struggling to understand this...
How can I find, using either Qt or cups, the minimum possible printer margins ?
Related
Result of my code:
Basically, what the issue is, the transparent part of my image are not blending correctly with what is drawn before it. I know I can do a
if(alpha<=0){discard;}
in the fragment shader, the only issue is I plan on having a ton of fragments and don't want the if statement for each fragment on mobile devices.
Here is my code related to alpha, and depth testing:
var gl = canvas.getContext("webgl2",
{
antialias : false,
alpha : false,
premultipliedAlpha: false,
}
);
gl.enable(gl.BLEND);
gl.blendFunc(gl.SRC_ALPHA, gl.ONE_MINUS_SRC_ALPHA);
gl.enable(gl.DEPTH_TEST);
gl.depthFunc(gl.GREATER);
Also, these are textured gl.POINTS I am drawing. If I change the order the two images are drawn in the buffer, the problem doesn't exist. They will be dynamically rotating during the program's runtime so this is not an option.
It's not clear what your issue is without more code but it looks like a depth test issue.
Assuming I understand correctly you're drawing 2 rectangles? If you draw the red one before the blue one then depending on how you have the depth test setup the blue one will fail the depth test when the X area is drawn.
You generally solve this by sorting what you draw, making sure to draw things further away first.
For a grid of "tiles" you can generally sort by walking the grid itself in the correct direction instead of "sorting"
On the other hand, if all of your transparency is 100% draw or not draw then discard has its advantages and you can draw front to back. The reason is because in that case drawing front to back, the pixel drawn (not discarded) by the red quad will be rejected when drawing the blue quad by the depth test. The depth test is usually optimized to happen before running the fragment shader for a certain pixel. If the depth test says the pixel will not be drawn then no reason to even run the fragment shader for that pixel, time saved. Unfortunately as soon as you have any transparency that is not 100% opaque or 100% transparent then you need to sort and draw back to front. Some of these issues are covered in this article
A few notes:
you mentioned mobile devices and you mentioned WebGL2 in your code sample. There is no WebGL2 on iOS
you said you're drawing with POINTS. The spec says only POINTS of 1 pixel in size are required. It looks like you're safe up to points of size 60 but to be safe it's generally best to draw with triangles as there are other isses with points
you might also be interested in sprites with depth
I've noticed that whenever I use magenta.js's built in Visualizer method, it renders ever so slightly blurry (perhaps an anti-aliasing issue?) notes. I've attached an image:
I can see this with varying intensities across many of the documentation's examples as well, such as https://piano-scribe.glitch.me/. Is there a way I can get sharp edges or at the least minimize the blurriness? I'm not sure whether this issue has been addressed or is suitable in the magenta github, so I'm posting here.
Edit: with image-rendering: pixelated on the canvas element, zoomed in.
This is a bug (if you call it that) with magenta-js's visualizer. Taking a look at the redraw method in their source reveals that the x position and w(idth) of each note are determined with the following lines.
const x = (this.getNoteStartTime(note) * this.config.pixelsPerTimeStep) +
offset;
const w = (this.getNoteEndTime(note) - this.getNoteStartTime(note)) *
this.config.pixelsPerTimeStep;
Now, when drawing on a canvas, if you don't draw at an integer, the browser will interpolate and try to draw a close representation, resulting in the miscolored pixels you noticed.
All that's left to do is confirm that x and/or w are not integers. I loaded the demo page, opened the relevant js file in the sources tab, searched for this line and put a breakpoint.
Sure enough. x = 13.8 and w = 15.35999. I've submitted magenta-js#238 with a fix.
I need to get the actual height of QTextDocument in order to be able to set the containing QPlainTextEdit to a minimum height (while keeping its width constant) so that it shows the whole content without the vertical scrollbar. I tried to follow this question (closed with with accepted answer) How do I determine the height of a QTextDocument? but it does not do what it promises.
A piece of code:
from PyQt5.QtWidgets import QApplication, QPlainTextEdit
app = QApplication([])
w = QPlainTextEdit()
w.setPlainText("Hello!")
print(w.document().size())
w.setPlainText("Hello!\nHello again!")
print(w.document().size())
prints out:
PyQt5.QtCore.QSizeF(35.0, 1.0)
PyQt5.QtCore.QSizeF(64.0, 2.0)
It seems that the width is measured correctly in pixels but the height just shows the number of lines instead of pixels. I think multiplying it with font pixel metric height does not help because there can be mixed formatting (in general it can be a rich text / HTML) and line spacing, document margins and maybe some other complicated stuff based on implementation details... etc.
So is there a way out?
So I finally found a solution but it is really ugly. If anyone knows anything better, please publish it.
from PyQt5.QtWidgets import QApplication, QPlainTextEdit
app = QApplication([])
w = QPlainTextEdit()
# test various formatting
w.appendHtml("<h1>Hello!</h1>")
w.appendHtml("<b>Hello!</b>")
w.appendPlainText("Hello!")
doc = w.document()
layout = doc.documentLayout()
h = 0
b = doc.begin()
while b != doc.end():
h += layout.blockBoundingRect(b).height()
b = b.next()
# magic formula: I do not know why the document margin is already
# once included in the height of the last block, and I do not know
# why there must be the number 1 at the end... but it works
w.setFixedHeight(h + doc.documentMargin() + 2 * w.frameWidth() + 1)
w.show()
app.exec_()
So this should show the box without scroll bar. If you decrease the height by 1, the scroll bar appears. This should work with any number of lines, document margins, frame widths, formatting etc. Hopefully.
Shot in the dark without testing
Have you looked # pageSize?
From the docs:
This property holds the page size that should be used for laying out the document
The units are determined by the underlying paint device. The size is
measured in logical pixels when painting to the screen, and in points
(1/72 inch) when painting to a printer.
By default, for a newly-created, empty document, this property
contains an undefined size.
If you set the pageSize, as directed by the other thread, I'd expect you'd get the value out in the pixels that QPlainTextEdit::setMinimumHeight needs.
I'm scaling a QImage, currently as so (I understand there may be more elegant ways):
img.setDotsPerMeterX(img.dotsPerMeterX() * 2);
img.setDotsPerMeterY(img.dotsPerMeterY() * 2);
When I save:
img.save("c:\\users\\me\\desktop\\test.jpg");
and subsequently open and print the image from Photoshop, it is, as expected, half of the physical size of the same image without the scaling applied.
However, when I simply print the scaled QImage, directly from code:
myQPainter.drawImage(0,0,img);
the image prints at the original physical size - not scaled to half the physical size.
I'm using the same printer in each case; and, as far as I can tell, the settings are consistent between both print cases.
Am I misunderstanding something? The end goal is to successfully scale and print the scaled image directly from code.
If we look at the documentation for setDotsPerMeterX it states: -
Together with dotsPerMeterY(), this number defines the intended scale and aspect ratio of the image, and determines the scale at which QPainter will draw graphics on the image. It does not change the scale or aspect ratio of the image when it is rendered on other paint devices.
I expect that the reason for the latter case being the original size is that the image has already been drawn before the call to the functions to set the dots per meter. Or alternatively, set the dots per meter on the original image, before loading its content.
In contrast, when saving, it appears that the device which you save to is copying the values you have set for the dots per meter on the image, then drawing to that device.
I would expect creating a second QImage, setting its dots per meter, then copying from the original to that second image, it would achieve the result you're looking for. Alternatively, you may just be able to set the dots per meter before loading the content on the original QImage.
I have a pdf file which needs to be converted to postscript ( using pdf2ps ) and sent to an old ( Lanier 2145 ) printer. This file has a code at the very bottom of one of the pages, which unfortunately is being cut off.
After spending a long time mucking about with CUPS trying to get it to scale, we have given up and starting to manipulate the actual ps file.
I can scale the pages using
<</Install { .80 .80 scale } bind >> setpagedevice
However, the scaling is being locked to the bottom left hand corner rather than scaling from the center. This means that the very bottom of the page is still cut off, no matter what the scale.
How can you set where the scaling is done from? I would prefer to scale from the center, but could live with scaling from the top.
Thanks
You can do a translate in the procedure and move the origin. For example:
<</Install { 18 18 translate .80 .80 scale } bind >> setpagedevice