GetStringWidth has changed from v4.1.2 to v4.4

Aspose.PDF Product Family
1

Hi,


I’ve just downloaded v4.4 of .NET for PDF to resolve the “Index was outside the bounds of the array.” error we were occasionally getting when calling getBuffer. It is indeed fixed in v4.4

However, we make extensive use of getStringWidth, and this seems to be returning different result in v4.4 than it did in v4.1.2

TextInfo ti = new TextInfo();
ti.FontName = “Times”;
ti.FontSize = 10;
return pdf1.GetStringWidth(“hello world”, ti);

The above code returns 45.842 in v4.1.2 but only 45.83 in v4.4

Obviously with much larger strings there is a much bigger difference.

Please tell me there’s something I/you can do to get this to return the same result it used to??
2

Hello Duane,

I have tested the scenario and I am able to reproduce the same problem. For the sake of correction, I have logged it in our issue tracking system as PDFNET-17603. We will investigate this issue in details and will keep you updated on the status of a correction.

We apologize for your inconvenience.

3

Hello Duane,


We have made some improvements/bug fixes in our font engine and size calculations since v4.1.2, so string width may has more correct value.

As I can see You use ‘Times’ font in your examples, but the font isn’t standard for pdf readers (see http://www.aspose.com/documentation/.net-components/aspose.pdf-for-.net/use-pdf-core-fonts.html). If you want to get precision values in result of font calculations you should use only embedded fonts (see http://www.aspose.com/documentation/.net-components/aspose.pdf-for-.net/font-handling.html) because they are have fixed sizes in any pdf document.

4

Thanks for the update.


So to clarify, are you saying this was a deliberate change and it will be staying as it is? That’s fine if that is the case, we’ll just adjust our code.

Are there likely to be any changes again to the way this is calculated?
Is there any easy calculation I can apply to convert width values pre v4.1.2 to get the values now? ie, will they always be 3% less or similar?

What I don’t understand though is this. GetStringWidth returns X. Therefore we set the width of a cell in a table to X and the text fits in the cell without any wrapping.

With the new calculations this doesn’t work as if we use the value from GetStringWidth to set the cell width then the cell isn’t wide enough and the text is wrapped.
5

Hello Duane,


Could you publish a sample code for the text wrapping issue for our investigation?

There is no exact calculation for old and new version, and unfortunately we can’t guarantee the Pdf.GetStringWidth algorithm will be unchanged in the nearest release, but I think the correction value isn’t greater than 0.001 point on each char for Times, 10 or ~0.0001*P, where P is size font in points.

Also the GetStringWidth isn’t the best method for table cell width calculation. I’d like to recommend you use GetMaxColWidth/SetColumnWidth methods (see http://www.aspose.com/documentation/.net-components/aspose.pdf-for-.net/aspose.pdf.table.getmaxcolumnwidth_overload_2.html).

The GetMaxColWidth returns correct cell width value depend on text, cell padding, border width.

Here is a sample:

string[] str = {“Lorem ipsum”, “Lorem ipsum dolor set amet”, “123”};
Pdf pdf = new Pdf();
Section section = pdf.Sections.Add();
TextInfo ti = new TextInfo();
ti.FontName = “Courier New”;
ti.FontSize = 10;

Table table = new Table();
table.DefaultCellBorder = new BorderInfo((int)BorderSide.All, new Color(“Blue”));
MarginInfo defPadding = new MarginInfo();
defPadding.Left = 20;
defPadding.Right = 20;
table.DefaultCellPadding = defPadding;
table.DefaultCellTextInfo = ti;
Row row = table.Rows.Add();

//fill table

for(int i = 0; i < 3; i++)
{
Cell cell = row.Cells.Add();
cell.Paragraphs.Add(new Text(str[i]));
}

//it’s to adjust column width

for (int i = 0; i < 3; i++ )
{
table.SetColumnWidth(i, table.GetMaxColumnWidth(pdf, i));
}

section.Paragraphs.Add(table);


We apologize for your inconvenience.
6
Re-writing this is going to cost us a lot of time and hassle. And if it's possible that we'll need to re-write again in the future then it's not something I'd want to commit the time to getting done.

Is there any possibility of you adding a flag/setting so we can force the dll to use the same calculations from v4.1.2?

If you change fundamental stuff like this without giving users the ability to stick with the old way of doing it then it's not possible to build an application using your software.
7

Hello Duane,

Sorry for replying you so late.

We have reverted back the mechanism to return values for GetStringWidth as presented in 4.1.2. It will be included in the latest version of Aspose.Pdf for .NET which will be published sometimes soon. Please be patient and spare us little time. Once the version becomes available, we would be pleased to update you with the status of correction.

Thanks for your cooperation and understanding. We are sorry for the delay and inconvenience.

8

Thank you, that’s excellent news and has really made my day!


I’ll look forward to hearing when the next release is out.

Thanks again

Duane
9

The issues you have found earlier (filed as 17603) have been fixed in this update.

This message was posted using Notification2Forum from Downloads module by aspose.notifier.
10

I didn’t get a chance to test this in 4.5.0, but we’ve just tried 5.0.1 and this issue is still present.

Has it been accidentally re-introduced? : /

11

Hello Duane,

I have tested the scenario using following code snippet with Aspose.Pdf for .NET 5.0.1 over WindowsXP SP3 and as per my observations, the method pdf.GetStringWidth is returning 45.842. Can you please share the code snippet that you are using so that we can test the scenario at our end. We apologize for your inconvenience.

[C#]

Pdf pdf = new Pdf();
Aspose.Pdf.Section section = pdf.Sections.Add();
Aspose.Pdf.TextInfo ti = new Aspose.Pdf.TextInfo();
ti.FontName = "Times";
ti.FontSize = 10;
MessageBox.Show("" + pdf.GetStringWidth("hello world", ti));