We’re experiencing a slow execution of the “ListLabel.Export” method in some specific scenarios.
Our pdf reports are generated from data stored in a MSSQL DBs, containing same amount of data in different languages.
The same project data (project stream) are used for all languages.
For some reason we experience different execution time of the “ListLabel.Export” method, as follows:
DB with data in English: 2227.8 ms
DB with data in Japanese: 112539.4 ms
DB with data in Chinese: 90805.3 ms
Note: all DBs contain the same amount of data, strings in DB are localized while seeding with default data.
nice to welcome you here to our forum and thanks for your observation.
Does your observation regarding the performance only apply to the PDF export of List & Label or can you also reproduce the same behavior in the context of a preview export? To make it export to a List & Label preview file instead of a PDF file, you can use this code here:
...
ExportConfiguration expConf = new ExportConfiguration(LlExportTarget.Preview, @"myPreviewFile.ll", @"myProjectFile.lst");
LL.Export(expConf);
...
The reason why I ask is, that during the PDF export, the handling of the fonts can lead to performance issues, if the font used in the project file does not support the characters to be displayed, for example, and an alternative font has to be selected during the PDF export, which has to be searched for in the system. This would fit very well with the fact that the reports for the Asian variants - here Japanese and Chinese - take considerably longer than the report with the English data/texts. Because here every single character has to be searched out and replaced in the system, so that it can be embedded as a font in the PDF document. If, however, a suitable font for Japanese or Chinese texts is already used in the project, the time-consuming selection of the font for the PDF export is no longer necessary and it should be much faster. Whether in your case the font “MS Microsoft Unicode” is sufficient, I can not say yet, because it also depends on the correct display of the respective characters - but it would be worth a try.
Finally, it is also interesting to know with which version (incl. Service Pack) of List & Label you are working.
I hope that the information provided can already help a little to narrow down the cause - or even solve it.
Thanks for your quick response.
In case of preview, I do not experience difference in execution time.
Does the font processing flow (searching alternative font) apply only for the PDF export?
We are using List&Label version 26.0.
Is there a way to find out if the fonts are causing this issue?
At first sight, it looks like the font used is: Arial (maybe there is usage of other font as well in specific areas).
I don’t want to go into too much detail here, but in case of the preview export selecting the font and the correct chararcters is mostly done automatically by GDI(+). But while exporting into the PDF format the font and its characters need to be embedded into the PDF format to be able to display the PDF document on different systems always correctly - also if the font may not exist on the target system.
But you also mentioned that you only use 26.000 - without a service pack and thus the RTM variant.
In fact, there have already been some service packs for version 26 where there were various adjustments for the PDF export, such as in version 26.005 - see also our blogpost New Service Pack 26.005 for List & Label and the Report Server about this.
Therefore I would suggest to install the current official service pack of List & Label 26 and check the behavior again. Besides the entries in the blogpost above, the installation of service pack 26.005 also installs a detailed PDF document ServicePack.pdf in folder …\Documentation\EN, which contains even more information and details about the adjustments - again especially for PDF export and especially when dealing with fonts for asian texts - here is an snippet of it:
If you haven’t already downloaded it, it will be difficult to find the version. For legal reasons, I believe combit is no longer allowed to offer it.
Your only option is to upgrade to the latest version of combit.
Well, nice. That is basically a new product, with associated expenses etc.
I find it strange and disturbing, that we have a licensed product, and the service packs are not available.
Basically, the service pack should be part of the product itself.
This should rather be explained to you by a combit employee, I am out of here, maybe it would be better to contact combit directly, good luck and have a nice day.
If you bought a Standard Edition (which sounds like what you did) you have access to the service packs for this version 12 months. Our subscription versions work differently (access to all versions released during the subscription period). In order to help you here feel free to contact our sales team referring to this thread and ask for a one time exception from this policy.
If the described behavior persists, it will slowly become difficult within the scope of the forum to track down other possible causes in detail. Therefore, the following suggestions in advance:
a) You could have a look here now once purposefully in the project where exactly which fonts are used - in particular for the Asian text editions, since these make the difference! But if - as you already mentioned - “Arial” is used, then this will not be sufficient to select the Asian text outputs for the PDF export quickly and correctly. Here I would try at least once to switch to the font “Arial Unicode MS”. But it is important to check and update the whole project file afterwards. Because as soon as only one place is overlooked, the time-consuming search and selection of the individual Asian characters will again take a very long time.
Tip: To keep the complexity to a minimum, I would create a new project file for a quick test and place relevant texts there from the data source accordingly, which just differ in EN and Japanese/Chinese and perform a new measurement. Depending on how large and complex the current project file is, there is a very high chance to miss something when checking the settings for the fonts of the different objects.
b) Otherwise, please give the latest version of List & Label 28 a chance and check if the behavior
is there the same or whether there is already an improvement in the new version - in direct comparison to version 26. This can also be done quite easily with the free available Trial Edition.
Otherwise, we would have to analyze everything else in detail as part of a ticket in our Support Center, where we would then also have to receive a comparable application from you for testing. This is the only way we can take a closer look in development and identify possible causes.
