Bill,
The main thing here is screen resolution. As said, Excel shows different stuff depending in your screen resolution, and it makes it impossible to have an exact calculation that would work everywhere. Now, that being said, ColMult is very accurate (at leas for print preview of a 600 dpi printer). We calculated it back in 2005 by looking at the physical output of more than a dozen of laser printers, measuring the actual output in paper with an old fashioned ruler, and averaging the results. I remember it because I traveled to australia to do that (among a lot of other stuff of course).
But even when colmult is targeted to high res (600 dpi), differences aren't that big as to justify an 1.3 adjustment factor. There is something else going on.
And I think you just gave the answer in this line:
Canvas.TextWidth(MyString);
Alas, Canvas uses GDI, which isn't either resolution independent. This means, the number of pixels you will get will depend (a lot) in the screen dpi. You can make a simple test:
In an empty project, drop a button and write this code:
const
s = 'A little test!';
procedure TForm12.Button1Click(Sender: TObject);
begin
ShowMessage(IntToStr(Canvas.TextWidth(s)));
end;
Then run it at different dpi settings. Here with 96dpi (100% scaling in modern windows) I get 56. But if I run it at 150%, I get 89, which makes sense because 56*1.5 = 84. (the difference between 84 and 89 is because the text rendered at a higher resolution is a little bigger due to pixel rounding)
Now, as you can imagine, passing 56*RowMult or 89*RowMult will get completely different results: After all the file generated is the same, and the value you write in the xls/x file shouldn't depend on if you were running at 100% or 150%.
So you can't use the output of Canvas.TextWidth as it. This is one of the reasons FlexCel itself doesn't use Canvas at all, because it uses GDI which is resolution dependent. (The other reason being that canvas is not thread aware, so we would need to use Canvas.Lock a lot to be sure FlexCel can be used in multithreaded apps). We use GDI+ everywhere.
So my first question would be: Do you have 96dpi (100%) screen scaling in your pc? But even if you do, your customers might not, so I would use Canvas.Font.PixelsPerInch as an adjustment. This will return 96 if you are running at 100%, 144 if you are running at 150, etc.
If the first question is ok (you are testing at 96 dpi), do you have an example on what cases you need 1.3 adjustment? I've tried the example you sent me last time here using 1.0 (instead of 1.1 which you used and should probably use) and it works fine. Column widths are ok.
Third point: As you know, strings inside a cell might have different fonts. So for example you might have a cell which has a font of arial 8, but inside you select all the text and make it times new roman 12. If you have any rich text inside the cells, then you can't just use Canvas.TextWidth. But XlsFile.AutoFitCol supports rich text too, so you could use that.
Well, this is what I can think of. Your factor 1.3 is highly suspicious because 96/72 = 1.3333, and it looked like ti could be some conversion issue between "windows pixels" (96 per inch) and "everyone else pixels (72 per inch)
As you can see here:
But looking at the code you sent last time, I could't find a place where you forgot to convert from 96 to 72. On the other hand, the code you sent last time works with 1.0 factor. In any case, I personally prefer to use ExcelMetrics.ColMultDisplay (which gives results in 1/100 of an inch, so I need to think in what I need to convert that to). But this is a personal preference, ColMult should work fine, using a "pixel"of 1/96 of an inch.