We are using TrueType fonts and XSL-FO to render PDFs in different languages/scripts.

We had a problem with a long delay generating PDF. This delay has been removed by setting IsTruetypeFontMapCached = true and setting TruetypeFontMapPath, so we know the cause.

However, setting TruetypeFontMapPath is not an option in the production system because of the security policy. Everything is done using memory streams and the Aspose PDF will not be able to access the font map xml file on the file system. Is there a way of using something else (for example a memory stream) instead of a file to store the font map xml?

Alternatively, can the XSL-FO include a specific font name or font family in a way that removes the need to look up the entire font map? (Currently we use <fo:block font-size="10pt" font-family="verdana"> and suchlike.)

Please let me know if there is a workaround, or any Aspose upgrade plans to resolve this, because otherwise we may not be able to use Aspose PDF after all.

Hi,

Thank you for considering Aspose.

Creating the font map takes long time so we save the file on disk. If we save it in memory, it will still takes long time create the font map when create a new Pdf object. We can consider adding a new class named FontMap, you can cerate it once when the application starts. If the application restart, the FontMap object will have to be create again. Can that be acceptable?

---

Tommy Wang
Lead Developer
Aspose Changsha Team
About Us
Contact Us

So the PDF class would then have a FontMap property we can get/set? We would then persist a serialized FontMap object ouselves (not to file system), and deserialise that object to set PDF.FontMap when app restarts.

If this is what you are proposing then it does sound like a solution. Please can you indicate how soon this implementation would be available.

You are right. I think we can support this feature at the end of next week.

---

Tommy Wang
Lead Developer
Aspose Changsha Team
About Us
Contact Us

In that case we will hope to use Aspose PDF. Unfortunately our development has to be completed by end of Friday 5 September, so I wonder if there will be any overlapping day when we can update our code for the new Aspose PDF. Please can you indicate actual release date planned (once known) for your next release that would include this feature, so we can make a decision.

Hi,

We will try to support this feature by next wednesday (3rd Oct.) and provide a new dll to you before publishing the official hotfix. Can that be accepted?

---

Tommy Wang
Lead Developer
Aspose Changsha Team
About Us
Contact Us

That is good news because if we have the dll on Weds that will give us time to finalize our PDF development from Weds to Fri and we hope this will result in us staying with Aspose PDF. Thank you for your prompt and helpful responses.

Hi,

The feature is supported now. Please try the attachment before new hotfix.
Best regards,

---

Hans Zhang
Product Developer
Aspose Changsha Team
About Us
Contact Us

Wow, that was quick, thanks! Could you let me know where to find the attachment please and we'll try it out.

Also a question: we use multiple servers and we have to store a single font map in our central configuration which is not server-aware. When we set TruetypeFontMapStream, does it matter if the font map was not actually created on the current machine? (Obviously the fonts we actually use in the PDFs will exist on all machines.) Do you foresee any problem with this approach?

Hi,

The dll is attached. Please try it before official hotfix.

For your problem, our developer will answer your question soon.

Best regards.

---

Hans Zhang
Product Developer
Aspose Changsha Team
About Us
Contact Us

With the new dll, we have gone back to a long delay again on first Save (about 15 seconds delay, but only the first Save, and thereafter about 2 secs). This behaviour is the same as we were seeing before setting IsTruetypeFontMapCached = true. So it seems we are not successfully setting the fontmap? This is our code:

    Pdf OutputPDF = new Pdf();

    //TODO - do this once on deployment, and store the string in configuration
    MemoryStream FontMapStream = Pdf.CreateTruetypeFontMapStream();
    FontMapStream.Seek(0, SeekOrigin.Begin);
    Byte[] FontMapBytes = new Byte[FontMapStream.Length];
    FontMapStream.Read(FontMapBytes, 0, (int)FontMapStream.Length);
    string FontMapBase64String = Convert.ToBase64String(FontMapBytes);

    //TODO get string back from configuration for use here
    string FontMapBase64String2 = FontMapBase64String;
    Byte[] FontMapBytes2 = Convert.FromBase64String(FontMapBase64String2);
    MemoryStream FontMapStream2 = new MemoryStream();
    FontMapStream2.Read(FontMapBytes2, 0, (int)FontMapBytes2.Length);
    OutputPDF.IsTruetypeFontMapCached = true;
    OutputPDF.TruetypeFontMapStream = FontMapStream2;

    //Bind and print the PDF
    OutputPDF.BindFO(TheTransformedXmlMemoryStream);
    MemoryStream TheOutputStream = new MemoryStream();
    OutputPDF.SetUnicode();
    OutputPDF.Save(TheOutputStream);

Hi,

It is normal that it takes about 15 seconds for the first Save, and thereafter about 2 secs. There is no error in your code. If you don't set the font map, it will take long time for each Save.

---

Tommy Wang
Lead Developer
Aspose Changsha Team
About Us
Contact Us

I should have made clear that by "first save" I refer to the first save after the dll has been loaded by the webserver. All saves (with and without any font map cache) are quick after that. That is the original problem we were trying to solve: the long delay of an extra 15-30 seconds on this one line of code, every time the first user tries to view a PDF when the webserver has been restarted or the app pool recycled.

Please note that the long delay is removed when we use the (old) file-system-based font map cache. The Save always takes 2 seconds even after a webserver restart.

We expected the delay to also be removed by using the new memorystream-based font map cache, but to our surprise it is not.

Unfortunately, as things stand, using the memorystream brings no gain at all. So we may not be able to use Aspose PDF after all, if there can be long delays of 15-30 seconds before even a tiny page is shown. So please can you consider this further? Surely setting the font map from a memorystream ought to produce the same performance benefit as setting it from the file system? (Or even better performance!)

Hi,

First I want to share my test result:
run it for first time:
create map time used: 00:00:10.5625000
create pdf time used: 00:00:03.5312500

run it again:
create map time used: 00:00:06.3750000
create pdf time used: 00:00:01.4218750

run it again without font map
create pdf time used: 00:00:07.9843750
As you can see, without font map setting, the time for Pdf generating will be much longer even you run the application for many time. The reason is that the font map will be created each time. Using the font map in memory you can create the font map only one when you restart the server. If the font map is saved on disk you need not recreate it when restart the server. Since you can't save the file, you have to create it once when the server is srart. We can't provide better solution.

---

Tommy Wang
Lead Developer
Aspose Changsha Team
About Us
Contact Us

Sorry but you have not understood! May I put it another way. This is what we are seeing.

using old method:
pdf.IsTruetypeFontMapCached = true;
pdf.TruetypeFontMapPath = @"c:\";
create pdf
restart webserver: create pdf time 2 secs
restart webserver: create pdf time 2 secs
restart webserver: create pdf time 2 secs

using new memorystream method:
pdf.CreateTruetypeFontMapStream, and save the stream to our storage
restart webserver: set fontmap from saved stream: create pdf time 15-30 secs
restart webserver: set fontmap from saved stream: create pdf time 15-30 secs
restart webserver: set fontmap from saved stream: create pdf time 15-30 secs

As you can see, we only create the font map once. We do not create it every time. But using it does not produce the performance of the old method (see above), so something is not working.

So your memorystream fontmap would be a solution for us but it is not working yet. If you will try the same test (restart webserver and set from saved memorystream) I think you will see the same thing.