openNURBS C++ Toolkit

To use openNURBS in your C++ application, follow these steps:

1. Clone the repository to your local machine.
2. Build the library: Open opennurbs_public.sln in your IDE (e.g., Visual Studio), select your desired platform and configuration, and rebuild the solution.
3. Integrate into your project: Create a new C++ project and configure your header files to include the openNURBS public interface.

For detailed information on supported compilers and specific build instructions, refer to the official Getting Started guide.

// 1. Clone the repository
// 2. Open opennurbs_public.sln and rebuild
// 3. Configure your project headers

The example_test project is a basic test suite for verifying OpenNURBS FileIO functionality. To build and run it, ensure you have the prerequisites met and follow the CMake workflow from the src4/opennurbs/example_test directory.

Prerequisites

• Operating System: Linux, macOS, or Windows.
• C++ Compiler: Must support at least C++14 (tests are configured for C++17).
  • macOS: Apple Clang (via Xcode).
  • Windows: MSVC (via Visual Studio).
  • Linux: GCC.
• Build Tools: CMake (version 3.16 or higher) and a compatible build tool (Make, Ninja, or MSBuild).

# 1. Configure the project
cmake -S . -B build

# 2. Build the project
cmake --build build

# 3. Run the executable (Linux/macOS)
cd build && ./example_test -r ../../example_files

# 3. Run the executable (Windows)
cd build/Debug && ./example_test -r ../../example_files

To include openNURBS in your C++ project, you must define the installation directory and include the public header. It is recommended to do this in your stdafx.h file.

Use the OPENNURBS_PUBLIC_INSTALL_DIR macro to enable automatic linking via pragmas. Replace <MY_INSTALLPATH> with the absolute path to your openNURBS installation, ensuring you use forward slashes (/) as directory separators even on Windows.

If you intend to use openNURBS as a Dynamic Link Library (DLL), uncomment the OPENNURBS_IMPORTS definition.

// defining OPENNURBS_PUBLIC_INSTALL_DIR enables automatic linking using pragmas
#define OPENNURBS_PUBLIC_INSTALL_DIR "C:/PATH/TO/YOUR/INSTALLATION"

// uncomment the next line if you want to use opennurbs as a DLL
//#define OPENNURBS_IMPORTS

#include "C:/PATH/TO/YOUR/INSTALLATION/opennurbs_public.h"

gxvalid is a module designed to validate TrueType GX tables, which are additional tables used by Apple Advanced Typography (AAT) and QuickDraw GX Text. It also validates extended kern tables used for AAT.

Usage Patterns

• Library Integration: You can link gxvalid with your own program to validate a font file before running your layout engine. This allows you to remove error-checking code from your engine, as gxvalid handles the validation upfront.
• Stand-alone Validator: It can be used as a standalone font validator. The ftvalid test program (included in the ft2demo bundle) calls gxvalid internally, making it useful for font developers.

gxvalid uses the FreeType 2 validator framework (ftvalid).

The PCF (Portable Compiled Format) driver allows FreeType to load binary bitmap fonts commonly used in X environments. Glyph images are loaded into memory on demand to maintain a small memory footprint.

To use PCF fonts, you can compile existing BDF bitmap fonts into the PCF format using the bdftopcf utility (often found in XFree86 source trees).

Since libFuzzer typically only mutates a single input file, ftmutator.cc implements a custom mutator that uses an uncompressed tar file archive as the input.

How it works:

• The first file within the tarball is opened by FreeType as the primary font file.
• All subsequent files in the tarball are treated as auxiliary input for FT_Attach_Stream (used for loading files like AFM files for PostScript Type 1 fonts).

Compilation requirements are identical to ftfuzzer.cc.

gxvalid is designed to be permissive, continuing validation even when errors are found, similar to how Apple's rendering engines behave. The behavior depends on the selected validation level:

• FT_VALIDATE_DEFAULT: Warns about errors and continues. For example, it will warn about invalid feature numbers but continue validation.
• FT_VALIDATE_TIGHT: More strict. It may ignore certain broken segments (like broken LookupTable format 2) or abort on specific errors like invalid feature numbers (case 'a') while continuing on others (case 'b').
• FT_VALIDATE_PARANOID: The strictest level. It will abort on most specification violations, including too-short LookupTable format 0, broken prop bracketing, or invalid feature numbers.

The driver supports an extension to the BDF format (used by Mark Leisher's xmbdfed and Microsoft's SBIT tool) that allows for anti-aliased bitmaps. This is indicated by a fourth field in the SIZE keyword specifying the bits per pixel (bpp).

Supported bpp values and driver behavior:

• 1: Default (returns a 1-bit per pixel bitmap).
• 2: Four gray levels (returns an 8-bit per pixel pixmap).
• 4: 16 gray levels (returns an 8-bit per pixel pixmap).
• 8: 256 gray levels (returns an 8-bit per pixel pixmap).

The ftfuzzer.cc file provides a target function for fuzzing FreeType using libFuzzer or similar tools. To build it, you must compile both libfreetype.a and ftfuzzer.cc using a recent clang compiler with specific sanitization flags for coverage and bug detection. You also require header files from the libarchive library to handle tar files.

Build Steps:

1. Compile libfreetype.a and ftfuzzer.cc with clang using -fsanitize-coverage=edge,8bit-counters and -fsanitize=address,signed-integer-overflow,shift.
2. Link the resulting objects with libFuzzer (which provides the main function) and libarchive.
3. Execute the fuzzer against a test corpus.

# Recommended clang flags for building
# For fuzzer coverage feedback:
-fsanitize-coverage=edge,8bit-counters

# For bug checking:
-fsanitize=address,signed-integer-overflow,shift