QString str = QString::number((double)i, 'd', 1);
painter->drawText(100 + i * 800/9 - 6, 910, 40, 40, 0, str );
I would like to increase fontSize to 2x what is showing?
You could try something like this (haven't compiled code to see if it works!):
QFont font = painter->font() ;
/* twice the size than the current font size */
font.setPointSize(font.pointSize() * 2);
/* set the modified font to the painter */
painter->setFont(font);
/* draw text etc. */
painter.drawText(....);
Figured it out:
QFont font;
font.setPixelSize(12);
for(int i = 0; i < 10; i++){
painter->drawLine(100, 100 + i * 800/9, 900, 100 + i * 800/9);
str = QString::number((double)9 - i, 'd', 1);
painter->setFont(font);
painter->drawText(75, 100 + i * 800/9 - 6, 40, 40, 1, str);
}
this is the easiest way
painter.setFont(QFont("times",22)); //22 is a number which you have to change
Related
In QStyledItemDelegate subclass paint method, the following code does not wrap the date-text as expected:
int flags = Qt::AlignCenter | Qt::TextWordWrap | Qt::TextJustificationForced;
switch (index.column())
{
case TimeRole:
{
int boxW = 16, space = 5, leftSpace = 30;
QRect textRect = QRect(rect.left() + leftSpace + boxW + space, rect.top(), rect.width() - boxW - space - m_space - leftSpace, rect.height());
QDateTime time = QDateTime::fromMSecsSinceEpoch(model->m_eventTime);
QString timeStr = time.toString("yyyy-MM-dd HH:mm:ss");
painter->drawText(textRect, flags, timeStr);
break;
}
However, I think because there is a dash -, text does not wrap as expected, instead, the left and the right characters are hidden:
Here I ask you : How are we supposed to colorize the console background with only the COLOREF datatype as a parameter?
The most common way of colorizing background is by using windows header function system("color --")
However, this way is not possible, and I am tasked to find out if we can colorize the console background using only the COLOREF datatype.
I did some research, and what I came across was SetConsoleAttribute(), and the windows header function system("color --").
This is what I expect my code to be:
COLOREF data = RGB(255, 0, 0);//red, basically
SetConsoleBackground(HDC *console, data);
Any way of doing this? Thanks in advance.
[NEW ANSWER (edit)]
So #IInspectable pointed out the the console now supports 24-bit full rgb colors so i did some research and managed to make it work.
This is how i solved it:
#include <Windows.h>
#include <string>
struct Color
{
int r;
int g;
int b;
};
void SetBackgroundColor(const Color& aColor)
{
std::string modifier = "\x1b[48;2;" + std::to_string(aColor.r) + ";" + std::to_string(aColor.g) + ";" + std::to_string(aColor.b) + "m";
printf(modifier.c_str());
}
void SetForegroundColor(const Color& aColor)
{
std::string modifier = "\x1b[38;2;" + std::to_string(aColor.r) + ";" + std::to_string(aColor.g) + ";" + std::to_string(aColor.b) + "m";
printf(modifier.c_str());
}
int main()
{
// Set output mode to handle virtual terminal sequences
HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);
DWORD dwMode = 0;
GetConsoleMode(hOut, &dwMode);
dwMode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
SetConsoleMode(hOut, dwMode);
SetForegroundColor({ 100,100,20 });
SetBackgroundColor({ 50,100,10 });
printf("Hello World\n");
system("pause");
}
[OLD ANSWER]
The console only supports 256 different color combinations defined with a WORD which is 8 bits long. The background color is stored in the 4 higher bits. This means the console only has support for 16 different colors:
enum class Color : int
{
Black = 0,
DarkBlue = 1,
DarkGreen = 2,
DarkCyan = 3,
DarkRed = 4,
DarkPurple = 5,
DarkYellow = 6,
DarkWhite = 7,
Gray = 8,
Blue = 9,
Green = 10,
Cyan = 11,
Red = 12,
Purple = 13,
Yellow = 14,
White = 15,
};
To set the background color of the typed characters, you could do:
void SetWriteColor(const Color& aColor)
{
HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
SetConsoleTextAttribute(hConsole, static_cast<WORD>(aColor) << 4);
}
I used this link and added lots of enhancements related to GDI.
https://github.com/microsoft/Windows-driver-samples/tree/master/print/OEM%20Printer%20Customization%20Plug-in%20Samples/C%2B%2B/bitmap
The above samples generates a bitmap driver with output as a bitmap image. Now using the bitmap I am able to generate working PCL for monochrome. I need some help for enhancing it further to generate PCL for 16bpp, 24 color and gray scale
Can anyone suggest some samples where I could see the PCL commands written in C++?
The monochrome part works correctly but the remaining color or gray scale just produce a blank image. I am using GhostPCL to convert to jpeg for testing purposes.
Can anyone provide a sample for where given an appropriate bitmap there is some PCLstream as output?
If you can't provide an entire working sample, how about things in commands which need to be addressed.
The one obvious thing is the buffer, rowsize.
This is the PCL for monochrome.
https://mega.nz/file/rNlFFRYL#CDK_l6s9KojLzywI3drsO1yt_OaK7-n5TNWdj1x8Aa4
This is the PCL for TrueColor same document. Nothing is printed except text
https://mega.nz/file/jI0lXRxZ#DmjLiDlNR8CfisN9UsRgz0F-FwXgOC0DCkaRPxqYCh4
I am using ghostPCL to convert to jpeg.
Code for monochrome:
//Header
// Universal Exit
char bufUnivExit[10];
StringCchPrintfA(bufUnivExit, 10, "%c%s", 27, "%-12345X"); // 9 chars
MoveMemory(pOemPDEV->pBufStart, bufUnivExit, 10);
dwOffset += 9;
// PJL
char bufPJL[38];
StringCchPrintfA(bufPJL, 38, "%s%c%c", "#PJL COMMENT ROMFOBMAYCE TEST-PRINT", 13, 10); // 37 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufPJL, 38);
dwOffset += 37;
// PCL Esc
char bufEsc[3];
StringCchPrintfA(bufEsc, 3, "%c%s", 27, "E"); // 2 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufEsc, 3);
dwOffset += 2;
// Raster Res
char bufRes[8];
StringCchPrintfA(bufRes, 8, "%c%s%d%s", 27, "*t", pPubDM->dmYResolution, "R"); // 7 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufRes, 8);
dwOffset += 7;
// Units of Measure
char bufUOM[8];
StringCchPrintfA(bufUOM, 8, "%c%s%d%s", 27, "&u", pPubDM->dmYResolution, "D"); // 7 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufUOM, 8);
dwOffset += 7;
// Raster Presentation
char bufPres[6];
StringCchPrintfA(bufPres, 6, "%c%s", 27, "*r3F"); // 5 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufPres, 6);
dwOffset += 5;
// Orientation
char bufOrient[6];
if (pPubDM->dmOrientation == 1)
orient = 0;
else
orient = 1;
StringCchPrintfA(bufOrient, 6, "%c%s%d%s", 27, "&l", orient, "O"); // 5 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufOrient, 6);
dwOffset += 5;
// Paper Size
char bufPaperSize[6];
if (pPubDM->dmPaperSize == 1)
pageSize = 2;
else
pageSize = 3;
StringCchPrintfA(bufPaperSize, 6, "%c%s%d%s", 27, "&l", pageSize, "A"); // 5 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufPaperSize, 6);
dwOffset += 5;
// Set horizontal and vertical registration (page margins)
char bufRegistration[14];
StringCchPrintfA(bufRegistration, 14, "%c%s", 27, "&l-180u-360Z"); // 13 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufRegistration, 14);
dwOffset += 13;
//Code for Page
BYTE bitmapRow[1050];
BYTE compRow[2100];
DWORD dwRowSize = 0;
DWORD dwCompPCLBitmapSize = 0;
for (i = 0; i < pso->sizlBitmap.cy; i++) {
// Zero Memory hack for bottom of form black line
if (*(((PBYTE &)pso->pvScan0) + (i * pso->lDelta) + 319) == 0xFF)
ZeroMemory(((PBYTE &)pso->pvScan0) + (i * pso->lDelta), 320);
// Copy the bitmap scan line into bitmapRow and send them off to be compressed
ZeroMemory(bitmapRow, 1050);
ZeroMemory(compRow, 2100);
MoveMemory(bitmapRow, ((PBYTE &)pso->pvScan0) + (i * pso->lDelta), pso->lDelta);
dwRowSize = CompressBitmapRow(compRow, bitmapRow, pso->lDelta);
// Create PCL Row Heading
char bufPCLLineHead[9];
StringCchPrintfA(bufPCLLineHead, 9, "%c%s%d%s", 27, "*b", dwRowSize, "W");
if ((dwCompPCLBitmapSize + dwRowSize + strlen(bufPCLLineHead))
> pOemPDEV->dwCompBitmapBufSize) {
if (!GrowCompBitmapBuf(pOemPDEV)) {
//ZeroMemory(traceBuff, 256);
//StringCchPrintf(traceBuff, 256,
// L"Compressed bitmap buffer could not allocate more memory.");
//WriteTraceLine(traceBuff);
}
}
if (pOemPDEV->pCompBitmapBufStart) {
// write the PCL line heading to the buffer
MoveMemory(pOemPDEV->pCompBitmapBufStart + dwCompPCLBitmapSize,
bufPCLLineHead, strlen(bufPCLLineHead));
dwCompPCLBitmapSize += strlen(bufPCLLineHead);
// write the compressed row to the buffer
MoveMemory(pOemPDEV->pCompBitmapBufStart + dwCompPCLBitmapSize,
compRow, dwRowSize);
dwCompPCLBitmapSize += dwRowSize;
}
}
// Calculate size and create buffer
dwPageBufferSize = 21;
if (!firstPage)
dwPageBufferSize++;
bGrowBuffer(pOemPDEV, dwPageBufferSize);
// Add all Raster Header Lines
if (!firstPage)
{
// Add a Form Feed
char bufFormFeed[2];
StringCchPrintfA(bufFormFeed, 2, "%c", 12); // 1 char
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufFormFeed, 2);
dwOffset += 1;
}
// Position cursor at X0, Y0
char bufXY[8];
StringCchPrintfA(bufXY, 8, "%c%s", 27, "*p0x0Y"); // 7 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufXY, 8);
dwOffset += 7;
// Start Raster Graphics
char bufStartRas[6];
StringCchPrintfA(bufStartRas, 6, "%c%s", 27, "*r1A"); // 5 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufStartRas, 6);
dwOffset += 5;
// Raster Encoding - Run-Length Encoding
char bufRasEncoding[6];
StringCchPrintfA(bufRasEncoding, 6, "%c%s", 27, "*b1M"); // 5 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufRasEncoding, 6);
dwOffset += 5;
// Write out bitmap header PCL
dwWritten = pDevObj->pDrvProcs->DrvWriteSpoolBuf(pDevObj, pOemPDEV->pBufStart, dwPageBufferSize);
// Write out PCL plus compressed bitmap bytes
dwWritten = pDevObj->pDrvProcs->DrvWriteSpoolBuf(pDevObj, pOemPDEV->pCompBitmapBufStart, dwCompPCLBitmapSize);
// End Raster Graphics
char bufEndRas[5];
StringCchPrintfA(bufEndRas, 5, "%c%s", 27, "*rB"); // 4 chars
MoveMemory(pOemPDEV->pBufStart + dwOffset, bufEndRas, 5);
// Write out PCL end bitmap
dwWritten = pDevObj->pDrvProcs->DrvWriteSpoolBuf(pDevObj, bufEndRas, 4);
Can anyone suggest? I don't have working knowledge of PCL or C++ except learning it like this.
I have a problem, I am sending some data from a PC C++ app with this structure from a visual studio app:
puerto1.WriteLine(rpm + ";" + gea + ":" + speed + ";;" + fuel + "::" + boost + ";;;" + rtemp + ":::" + atemp + ";;;;" + gas + "::::" + brk + ";;;;;");
And then on the Arduino, I parse it in 9 different strings and when I want to display it on a screen it reports the problem of the pic attached.
It works correctly sometimes, but it stopped working correctly a few days ago and it haven't returned to work properly, it should print the strings indepently like:
XXX
XXX
XXX
XXX
XXX
Not like the image.
Arduino code:
#include <UTFTGLUE.h>
UTFTGLUE myGLCD(0, A2, A1, A3, A4, A0);
extern uint8_t BigFont[];
String command;
String part1;
String part2;
String part3;
String part4;
String part5;
String part6;
String part7;
String part8;
String part9;
void setup() {
Serial.begin(9600);
myGLCD.InitLCD();
myGLCD.setFont(BigFont);
myGLCD.clrScr();
myGLCD.setColor(255, 255, 255);
myGLCD.setBackColor(0, 0, 0);
myGLCD.print("RPMs", 1, 10);
myGLCD.print("Gear", 1, 40);
myGLCD.print("Speed", 1, 70);
myGLCD.print("Fuel", 1, 100);
myGLCD.print("Boost", 1, 130);
myGLCD.print("Asphalt Temp", 1, 160);
myGLCD.print("Air Temp", 1, 190);
myGLCD.print("Gas", 1, 220);
myGLCD.print("Brake", 1, 250);
myGLCD.print("Engine Brake", 1, 280);
}
void loop() {
if (Serial.available()) {
char c = Serial.read();
if (c == '\n') {
parseCommand(command);
command = "";
} else {
command += c;
}
}
myGLCD.setColor(255, 255, 255);
myGLCD.setBackColor(0, 0, 0);
myGLCD.printNumI(val1, 5, 20);
myGLCD.print(part2, 5, 50);
myGLCD.printNumI(val3, 5, 80);
myGLCD.print(part4, 5, 110);
myGLCD.print(part5, 5, 140);
myGLCD.print(part6, 5, 170);
myGLCD.print(part7, 5, 200);
myGLCD.print(part8, 5, 230);
myGLCD.print(part9, 5, 260);
myGLCD.print(part10, 5, 290);
}
void parseCommand(String com) {
part1 = com.substring(0, com.indexOf(";"));
part2 = com.substring(com.indexOf(";") + 1, com.indexOf(":"));
part3 = com.substring(com.indexOf(":") + 1, com.indexOf(";;"));
part4 = com.substring(com.indexOf(";;") + 2, com.indexOf("::"));
part5 = com.substring(com.indexOf("::") + 2, com.indexOf(";;;"));
part6 = com.substring(com.indexOf(";;;") + 3, com.indexOf(":::"));
part7 = com.substring(com.indexOf(":::") + 3, com.indexOf(";;;;"));
part8 = com.substring(com.indexOf(";;;;") + 4, com.indexOf("::::"));
part9 = com.substring(com.indexOf("::::") + 4, com.indexOf(";;;;;"));
int val1 = part1.toInt();
int val3 = part3.toInt();
}
problem image
I have a code, which converts plain BGR data to sf::Texture. "ifs" is opened ifstream to file which contains byte triplets of BGR colors (header of source file is omitted). And Width & Height 100% valid. In my example image is 800x600.
struct h3pcx_color_bgr { uint8_t b, uint8_t g, uint8_t r };
sf::Uint8* pixels = new sf::Uint8[width * height * 4];
h3pcx_color_bgr* fileData = new h3pcx_color_bgr[width*height];
ifs.read((char*)fileData, width * height * sizeof(h3pcx_color_bgr));
for (uint32_t i = 0; i < width*height; ++i) {
pixels[i * 4] = fileData[i].r;
pixels[i * 4 + 1] = fileData[i].g;
pixels[i * 4 + 2] = fileData[i].b;
pixels[i * 4 + 3] = 255;
}
This code works good, problem comes after. Once I draw my texture:
m_tex.update(pixels); //sf::Texture
m_sprite.setTexture(m_tex); //sf::Sprite
m_window->draw(m_sprite); // m_window is sf::RenderWindow
I have this annoying grey line in image below:
What I did:
Verified, that pixels contains valid value
Code snippet below (700 * 595 is inside "grey area") shows, that both pixels and fileData contains valid data (not grey color, which is appears just uninitialized memory).
auto f = fileData[700 * 595]; // 32, 31, 38
auto r = pixels[700 * 595 * 4]; // 38
auto g = pixels[700 * 595 * 4 + 1]; // 31
auto b = pixels[700 * 595 * 4 + 2]; // 32
"Grey" color is 204, 204, 204.
Tried to use sf::Image
If we do something like this:
img.create(width, height, pixels); // img is sf::Image
img.setPixel(700, 595, sf::Color::Blue);
And then convert it to sf::Texture, and draw. Result will be same image with grey area, but pixel 700, 585 will be blue!
If I get color value from "grey area":
auto clr = img.getPixel(700,600); //sf::Color(204,204,204)
So, it looks like, there are some hard-limit(???) on quantity of pixels (but I doubt it, since I've looked on actual SFML code, and did not found anything suspicious) or my stupid mistake. I would be very grateful, if someone can point out - why this grey line appears.
In the code:
auto f = fileData[700 * 595];
You are accessing pixel 500, 520. To access the pixel 700, 595 you have to use:
auto f = fileData[700 + 595 * 800]; // x + y * width
I would write this as a comment, but I lack the necessary reputation.
If any1 is wondering - It's just file is wrong, with this exact grey color in the end. Code is correct.