Windows-Macintosh compatibility

Though GDL objects and libraries are considered by GRAPHISOFT as platform independent,
the following difficulties occur when objects are manually moved from Windows to a Macintosh:

  • Windows fonts will be replaced by the default Macintosh font in objects and list templates and vice-versa. This can cause differences in the UI display of the 2 platforms.
  • Text type listing files (listset.txt, listkey.txt, list templates, etc.) could lose line breaks, therefore listing won’t work (non-utf-8 coded texts, in general)

Changing platform with binary libraries

To avoid the above problems, save a .pla archive file of your library on the first platform, then extract it on the second.
This way the non-utf-8 files will be converted correctly as well.

Images and HDPI support in GDL

Starting from ARCHICAD 21 real HDPI support is available for OS X devices. To provide this feature, scalable vector graphics (.svg) source images are used to create multi-representation .tiff images, containing versions of the same graphic at different resolutions. ARCHICAD decides at runtime which image resolution is the best for the current display device from the available set of 100%, 150%, and 200%.
On Windows platform 100% is the default resolution. However, images created from .svg files have a slightly different look on Windows plaform as well.
This option is only available via the LP_XMLConverter tool. The .svg source image files are automatically converted to .tiff images during library conversion. A .gsm object cannot handle .svg images, so make sure the image name reference strings in scripts contain the .tiff extension (or omit the extension).
Always test vector images in all resolutions (the .tiff images can be checked by any image editor, resolution-by-resolution) to avoid blurry images after scaling (use lines aligned to full pixels in the source .svg as much as possible. Same recommendation as for .png images.)
The syntax requirements of any .svg built-in image (where the image is compiled into the binary library part itself) in GDLPict, Picture, InfoPict .xml sections are the following:
  • MIME attribute is “image/svg”. In case the MIME-type and the source image extension is different, the conversion ends with a warning (MIME is “image/svg”, but the image file’s extension is not svg)
  • SectionFlags attribute is “1”. This flag triggers the .tiff conversion. If the image is an .svg and the flag is different, a warning is displayed during conversion (SectionFlags should be “1” in case of an svg image).
The rest of the image reference in GDLPict, Picture, InfoPict .xml sections have not changed. Make sure to get the extension of the source image right in the path.
Non-built-in images, which are directly referred by their name in the object scripts are handled by the LP_XMLConverter tool as well:
  • The .svg image should be part of the library source, but not in the _images folder.
  • The conversion creates the .tiff counterparts of the .svg source images to the exact same location. The .svg source images are also copied to the binary library to a separate folder (_svg_source name extension), to support the source.xml to .gsm to reverse.xml comparison workflow. This extra folder can be avoided by the -excludesvg option of the LP_XMLConverter tool.
Any kind of .svg to .tiff conversion failure results in a warning or an error during library builds.
For tutorials and examples on the subject and the LP_XMLConverter tool, check out the GDL Center Tips and Tricks guides.