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.
- 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 .tif 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 platform as well.
This option is only available via the LP_XMLConverter tool. The .svg source image files are automatically converted to .tif images during library conversion. Archicad cannot handle .svg images, so make sure the image name reference strings in scripts omit the .svg extension.
Always test vector images in all resolutions (the .tif 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 .tif 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 (aka. external) 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 folder of built-in images (xml source), outside folders containing libpartdata.xml (hsf source).
- The conversion creates the .tif 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 (external images to source_svg, built-in images to <libpartname>_svg_source), to support the source to .gsm to source comparison workflow. This extra folder can be avoided by the -excludesvg option of the LP_XMLConverter tool. Any kind of .svg to .tif conversion failure results in a warning or an error during library builds.
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.