How do I determine the number of characters in a particular font will fit to the screen?
Have a look at QFontMetrics. Using this, you can determine, among other things, the width of a particular string:
QFontMetrics metrics(myFont);
int width = metrics.width(myString);
Is this what you want?
Note: It is not possible to find the number of characters of a particular font that will fit on the screen since not all fonts are monospace. So the number of characters will depend on the actual characters.
you can also use QFontMetrics::elidedText passing available space (remember to reduce it with margins/paddings. Then call length on result string
Related
I am upgrading an existing retailer software to print a QR code on an EPSON TM 88 V using MS Pos for .Net 1.14.
The PrintBarcode function is straightforward to use for one dimensional barcode, like the Code93, and its size can be adjusted with the width and height parameters.
public abstract void PrintBarCode(PrinterStation station, string data, BarCodeSymbology symbology, int height, int width, int alignment, BarCodeTextPosition textPosition);
However, BarCodeSymbology QRCode (204) size does not seem to be adjustable with these height and width parameters.. The barcode prints fine, but is very tiny (about 5 mm width and height), regardless of the parameters value.
How can I adjust the size of the printed QR code?
The documentation for OPOS(EPSON OPOS ADK) rather than POS for.NET(EPSON OPOS ADK for.NET) has the following instructions:
Probably the same notes apply to POS for.NET.
Please try adjusting the Width parameter value to get the desired size.
3.6.2 Printing Size
Because the width and length of QR CODE are the same, printing is done to the inner part at a size closest to it by using the value specified by the Width parameter.
Therefore, the height of print is not affected by the Height parameter.
If the Height parameter is less than 0, an error occurs.
The print size is determined by the version of QR and the size of the module.
Because the version of QR is determined by the data length and type, you can use the size of the module to adjust the print size. If the two dimensional barcode cannot fit into the print area (depending on the paper width, layout settings, etc.) then OPOS_E_ILLEGAL is returned and at this moment ResultCodeExtended becomes zero.
For QR, it differs from other two dimensional barcodes; if the encoded data result is not known, then the print width cannot be obtained.
If the print width cannot be obtained, the page mode range for 90-degree rotated printing cannot be specified.
Therefore, within OPOS it calculates the number of code words of the encoded data.
Because of this reason, data amount can be correctly verified.
And here is a similar Japanese FAQ.
QR コードを印刷する方法＜EPSON OPOS ADK シリーズ＞
It depends on the amount of text of the data you want to print.
If it is a string like "www.microsoft,com" or "012345678" it will be a small QR printed.
When you extend the length of the data being sent to the printer, you will see the difference.
I've been looking at this page, as well as this code example and I've noticed that the x_advance, y_advance, x_offset and y_offset fields in hb_glyph_position_t are of the type hb_position_t, which is an alias to int32_t. I haven't found any documentation about which units are used for these fields. The examples above suggest that they're 64ths of something, but that's all I can infer.
Does anyone else know the exact unit implied by hb_position_t?
It is in input font size units (say pixels).
The idea there is you multiply the input font size by 64 then you divide the position by 64 after the shaping so you will be in control of how much sub pixel precision you need.
I am trying to convert a string into Code39 barcode. To increase the reliability I am trying to increase the font size of barcode from 40 to 60. Would this cause any issue as the width and height of the bars will change compared to the previous version of font 40?
No, the scanner reads the ratio between the width of the symbols. As long as they both scale the same way, you're fine. I doubt that you'll see increased reliability. I hope you'll post results.
Is there anyway to calculate the text's length when TextWidth = -1?.
I have a rectangle that has a QGraphicsTextItem in it, and I want to change the rectangle's width when characters exceed the rectangle.
I found this post by stopping on the same problem.
i'm using text->boundingRect().width()to get the width.
Perhaps it helps anybody
textWidth = -1 means, that
"[...] the text will not be broken into
multiple lines unless it is enforced
through an explicit line break or a
new paragraph."
(QTextDocument::textWidth())
So, if you want to get the length of your QGraphicsTextItem you can't use textWidth, but instead you need the actual length of the String within this QGraphicsTextItem. Have a look at QGraphicsTextItem::toPlainText(), which returns a QString. Call size() on that string.
int length = my_graphics_text_item.toPlainText().size()
Now you have the number of characters in this string and can implement a resize function to make your rectangle grow, when there are too many characters. It's a kind of workaround, but I hope it helps solving your problem.
You could also create a QFontMetrics([font of your QGraphicsTextItem]) instance and call its width(QString) function to obtain the width of the passed string in pixels, were it drawn in the specified fontfamily/-size/-weight.
Just obtaining the character count is only reasonable when using a monospaced font. In all other cases it's not a good idea.
I'm using GDI+ in C++. (This issue might exist in C# too).
I notice that whenever I call Graphics::MeasureString() or Graphics::DrawString(), the string is padded with blank space on the left and right.
For example, if I am using a Courier font, (not italic!) and I measure "P" I get 90, but "PP" gives me 150. I would expect a monospace font to give exactly double the width for "PP".
My question is: is this intended or documented behaviour, and how do I disable this?
RectF Rect(0,0,32767,32767);
RectF Bounds1, Bounds2;
graphics->MeasureString(L"PP", 1, font, Rect, &Bounds1);
graphics->MeasureString(L"PP", 2, font, Rect, &Bounds2);
margin = Bounds1.Width * 2 - Bounds2.Width;
It's by design, that method doesn't use the actual glyphs to measure the width and so adds a little padding in the case of overhangs.
MSDN suggests using a different method if you need more accuracy:
To obtain metrics suitable for adjacent strings in layout (for example, when implementing formatted text), use the MeasureCharacterRanges method or one of the MeasureString methods that takes a StringFormat, and pass GenericTypographic. Also, ensure the TextRenderingHint for the Graphics is AntiAlias.
It's true that is by design, however the link on the accepted answer is actually not perfect. The issue is the use of floats in all those methods when what you really want to be using is pixels (ints).
The TextRenderer class is meant for this purpose and works with the true sizes. See this link from msdn for a walkthrough of using this.
Append StringFormat.GenericTypographic will fix your issue:
graphics->MeasureString(L"PP", 1, font, width, StringFormat.GenericTypographic);
Apply the same attribute to DrawString.
Sounds like it might also be connecting to hinting, based on this kb article, Why text appears different when drawn with GDIPlus versus GDI
TextRenderer was great for getting the size of the font. But in the drawing loop, using TextRenderer.DrawText was excruciatingly slow compared to graphics.DrawString().
Since the width of a string is the problem, your much better off using a combination of TextRenderer.MeasureText and graphics.DrawString..