The coresuite designer Layouts are printed slow. What are the reasons?

• A) Analyze the CoresuiteDebugLog.xml.
• B) Printerdriver can not handle GDI (Graphics Device Interface) output nicely.
• C) Big pictures >1MB (logo) in the layout.
• D) The documents gets collected into printjobs (multiple documents gets rendered before printing).
• E) The machine CPU Power or RAM is insufficient.
• F) The usage of LD.QueryData("SELECT ...").
• G) The extensive usage of text manipulation.
• H) many line breaks in combination with LD.MultiLineRTF 

A) Analyze the CoresuiteDebugLog.xml

From coresuite Designer Version 7.35 onwards, we increased the information output in the coresuiteDebugLog. 

Now you can analyse in the logfile, how long it takes to process each step of the printing process, e.g.: 

</message> 
    <message level="1" date="09.04.2021" time="13:26:01"> 
      <description>LD: Data were prepared. It took 0:00:04,1283828</description> 
    </message> 
    <message level="1" date="09.04.2021" time="13:26:03"> 
      <description>LD: Document was rendered. It took 0:00:01,8542777</description> 
    </message> 
    <message level="1" date="09.04.2021" time="13:26:05"> 
      <description>LD: The view was loaded into SAP B1. It took 0:00:01,8889398</description> 
    </message> 
    <message level="1" date="09.04.2021" time="13:26:05"> 
      <description>LD: Worker queue job 'Preview' has ended. It took 0:00:10,9013435</description> 
    </message> 

Compare the duration values with those of the default layout (DOC00008).

B) Printerdriver can not handle GDI output nicely

Troubleshooting steps

• Start the printing.
• Open the coresuiteDebugLog.xml (Windows->Start->Run->%temp%->ENTER) and search for the term “Spoolertime”. This indicates how long it takes to submit the job to the spooler (printer). 
• If this value is high install the so called FinePrint – Tool (http://fineprint.com/fp/).
• Start printing again using the FinePrint Printer (adjust Layout Definition).
• Check the value in the coresuiteDebugLog.xml again and compare if it’s better. If yes go ahead with the solution.

Solution

C) Big pictures >1MB (logo) in the layout

Troubleshooting steps

• Create a backup of the layout. (Open the Layoutdefinition -> CTRL-D to duplicate the layout)
• Open the layout. Check for big pictures or pictures that load files dynamically (Property FullPath in the AdvancedPicture).
• Remove all pictures.
• Save the Layout.
• Print again.
• If it’s faster go ahead with the solution.

Solution

• Use smaller pictures/logos in your layout.
• Also check if there is an GDI optimized printerdriver available.
• Set the BUFFERING settings to TRUE to buffer the pictures from the hard-drive. Uses more RAM but does increase render speed. (Layoutdefinition -> Open Designer -> Choose the picture box -> Properties -> Buffering)

D) The documents gets collected into printjobs 

Troubleshooting steps

• There are no troubleshooting steps as the described behaviour is a feature. But it can be disabled as it is described in the solution. 

Solution

• To disable remove the Parameter AttGroup from your SelectGrid which is responsible for any grouping.

E) The machine CPU Power or RAM is insufficient

Solution

• Obviously install more RAM or use a faster machine.

F) The usage of LD.QueryData("SELECT ...")

Troubleshooting steps

• Check if the function LD.QueryData() is used in the layout. 
• If it is used in the layout, check the single queries how time consuming they are. Consider that especially in rows this function is extremely dangerous, it will be called per each line once to twice.

A little help to find LD.QueryData() in the layout

1. Open the layout in the designer.
2. Click on "File" -> "Save as".
3. Save on desktop as an xml-file.
4. Open the xml-file in notepad and search for "QueryData".

Solution

• Create new data sources on the Layout Definition instead of LD.QueryData() .

G) The extensive usage of text manipulation

Troubleshooting steps 

• Check if you use extensive text manipulation, especially on line level, e.g. string concatenation (with + or &)
• It is common programming knowledge that text manipulation of any kind is very time consuming,  no matter what programming language you use. 

Solution

• Try to optimize the scripts in the layout. You should use as little string manipulation as possible 

H) many linebreaks in OITM.UserText

Troubleshooting steps 

• Check if any text processed by LD.MultiLineRTF contains many linebreaks (e.g. OITM.UserText)

Solution

• The Function LD.MultiLineRTF replaces linebreaks with '<br/>' as it is needed in the AdvancedTextBox
• If the OITM.UserText contains many linebreaks, it may take a while for long documents to process and there is little you can do about it.
• If the customer can do without formatted text, you can use a normal textBox instead of AdvancedText - then you can remove the LD.MultiLineRTF also which should improve the performance.