Use of Delphi color constants?

Has anyone dealt with converting the Delphi RGB color constants to the separate floating point values used by QuickPDF?

I'd like to use values like clWhite and clBlack and clRed in my program that creates PDF files but before I write the code that translates these into separate RGB values I thought I'd ask if anyone has done this before.

I may have given you bad advice - what I said is what my code appears to do, but the documentation for SetLineColor says "Sets the outline color for any subsequently drawn graphics. The values of the color parameters range from 0 to 1, with 0 indicating 0% and 1 indicating 100% of the color."which is pretty darned clear that a Red byte value of 127 should be used as  (127.0 / 255.0) or ~0.50 and so on.  I have no idea why my code says otherwise and I do not recall any problems using color.  

The product is quite Delphi friendly.  I am doing a lot of experimenting with it, but the experiments almost always wind up with the code doing what it ought to, just not what my intuition thought.  One thing to keep in mind is that the orientation is multi-language, not just Delphi, so some of the conventions are not intuitive (to me).

I extend the TQuickPDF object and here is a piece of code I stuck in.

Procedure TQuickPDF.SetLineTColor(AColor : TColor);
var r,g,b : byte;
     begin
     TColorToRGB(AColor,r,g,b);
     self.SetLineColor(r,g,b);
     end;

this references a few of my library routines

Function  IntByte( int : integer; byt : byte = 0) : byte;
     begin  result := (int shr (byt * 8)) and $FF;  end;


Procedure TColorToRGB(c : TColor; var r,g,b :byte);
     begin
     r := intbyte(c,0);
     g := intbyte(c,1);
     b := intbyte(c,2);
     end;

Without writing a test program to prove it, I'm 99% sure the SetLineTColor does what it thinks it does.  I am happy to share my code, but it is literally millions of lines of code in units developed over 15-20 years (back to Turbo Pascal 1.0)

Now that I map my answer back to your question, I'm 99% sure my original thought was correct - just use the color bytes, not what the documentation implies as a number between 0 and 1.  Now I have to go back and test it...

Well that is really curious. Makes me wonder what version of QP you are using.

I have the QP 8.15 source code and it clearly takes the 3 RGB values passed to SetLineColor and directly emits them to the PDF file using the RG command after limiting those values to 0.0 to 1.0. The PDF specification also clearly describes the RG command as accepting floating point values from 0.0 to 1.0, not values from 0 to 255.

So I cannot explain what you are seeing.

I am also enhancing the TQuickPDF class with convenience functions so thanks very much for sharing your added method. I think I will adapt it to convert the values to fractions and pass them on then test both strategies.

Curiouser and curiouser.

Hi both,

I'm very sure, you are wrong about RGB-colorsetting in QPL. I did a small test to show why.

I wrote

QP.DrawText(0,0, 'before');
QP.SetTextColor(255, 127, 64);
QP.DrawText(0,0, 'after');

In case, that there would be anything converting it into 0..1 area, we had to find approx. 1.0 0.5 0.25 as values inside the PDF. For easier finding I made the both texts around.

But what is there:

BT               // begin text
1 0 0 1 0 0 Tm   // set text matrix
(before)Tj       // draw text
ET               // end text
1 1 1 rg         // set RGB-color
BT               // ...
1 0 0 1 0 0 Tm
(after)Tj
ET

You see there is no conversion, only a cut at 1.0, because values above would contradict the specification of PDF. So you should  for converting not spare the division by 255 to go from 0..255 to 0..1. There is no magic working for you.

Cheers

Werner

Yeah, I just finished a test program and found the same.

Now on to the other issues I have discovered.

From the PDF specification for version 1.4:

TABLE 4.9   Path construction operators

x y m = Begin  a  new  subpath  by  moving  the  current  point  to  coordinates (x, y),  omitting  any  connecting  line  segment.  If  the  previous  path construction  operator  in  the  current  path  was  also  m,  the  new  m overrides it; no vestige of the previous m operation remains in the
path.

x   y l (lowercase L)  =     Append a straight line segment from the current point to the point (x, y). The new current point is (x, y).

x1 y1 x2 y2 x3 y3 c = Append a cubic Bézier curve to the current path. The curve extends
from  the  current  point  to  the  point  (x3, y3),  using  (x1, y1)  and(x2, y2) as the Bézier control points (see “Cubic Bézier Curves,” below). The new current point is (x3, y3).

x2 y2 x3 y3 v = Append a cubic Bézier curve to the current path. The curve extends
from the current point to the point (x3, y3), using the current point and (x2, y2) as the Bézier control points (see “Cubic Bézier Curves,” below). The new current point is (x3, y3).

x1 y1 x3 y3 y = Append a cubic Bézier curve to the current path. The curve extends
from  the  current  point  to  the  point  (x3, y3),  using  (x1, y1)  and (x3, y3) as the Bézier control points (see “Cubic Bézier Curves,” below). The new current point is (x3, y3).
 
h = Close  the  current  subpath  by  appending  a  straight  line  segment from  the  current  point  to  the  starting  point  of  the  subpath.  This operator  terminates  the  current  subpath;  appending  another  segment to the current path will begin a new subpath, even if the new
segment begins at the endpoint reached by the h operation. If the current subpath is already closed, h does nothing.


Looks like "h" operator also results in a line to the originating point. Maybe that's what creates the vertical lines.

I have not yet seen any PDF content generated by QP that does not look like normal PDF "commands". I think it is possible to define something like a "macro" command and then use it in a PDF but I'm not 100% sure about that and have not seen it yet.

Hi,

there are a lot of things needed really to understand how a PDF is to be interpreted by any reader. It's a full time job. An easy entry to understand a first part is a look into appendix A (operator summery). But it is only a first step. Not only operators are working for us.

If you use QPL-(drawing-)commands and look in the resulting PDF, so you understand better, what QPL is doing for you and you get step by step ground under your feets.

Cheers,

Werner