OOM when using Libre Barcode EAN13 Text from Google Fonts

[andreiaugustin]

Bug Report

Description of the problem

When using Libre Barcode EAN13 Text, we go out of memory when trying to process GSUB substitutions. This was originally found in PDFKit.

Code sample

import * as fontkit from 'fontkit';

let font = fontkit.openSync(new URL('LibreBarcodeEAN13Text-Regular.ttf', import.meta.url));
const width = font.layout('123456789012', undefined, true).advanceWidth;

JS stacktrace

<--- Last few GCs --->

[8232:000001C145BA1000]    11886 ms: Scavenge (interleaved) 4048.3 (4125.2) -> 4045.4 (4128.2) MB, pooled: 0 MB, 14.38 / 0.00 ms  (average mu = 0.596, current mu = 0.447) allocation failure; 
[8232:000001C145BA1000]    11913 ms: Scavenge (interleaved) 4051.1 (4128.2) -> 4047.8 (4146.4) MB, pooled: 0 MB, 24.21 / 0.00 ms  (average mu = 0.596, current mu = 0.447) allocation failure; 


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 00007FF6F59F097D node::SetCppgcReference+17261
 2: 00007FF6F5958E08 v8::base::CPU::num_virtual_address_bits+92312
 3: 00007FF6F64D8B21 v8::Isolate::ReportExternalAllocationLimitReached+65
 4: 00007FF6F64C5A06 v8::Function::Experimental_IsNopFunction+2790
 5: 00007FF6F6315110 v8::internal::StrongRootAllocatorBase::StrongRootAllocatorBase+31392
 6: 00007FF6F63121AA v8::internal::StrongRootAllocatorBase::StrongRootAllocatorBase+19258
 7: 00007FF6F6327A41 v8::Isolate::GetHeapProfiler+7825
 8: 00007FF6F63282BA v8::Isolate::GetHeapProfiler+9994
 9: 00007FF6F6338D57 v8::Isolate::GetHeapProfiler+78247
10: 00007FF6F6001C7B v8::internal::Version::GetString+434555
11: 00007FF69656D4BA 

Your environment

• fontkit version: 2.0.0
• Node version: 22.13.1
• Browser version (if applicable): N/A
• Operating System: Windows

[andreiaugustin]

I have a possible fix for this in OTProcessor.applyLookups, where essentially substitution may insert glyphs ahead of the current position so we just skip them in order to avoid the lookup firing on its own output, but that might not work reliably for non-sequential substitutions? I've not played enough with this to know if there's chaining contextual subsitutions that may be affected if the code assumes they're in sequence?

        // OTProcessor.applyLookups
        ...
          continue;
        }

        let prevLen = glyphs.length;
        let res = false;
        for (let table of lookup.subTables) {
          let res = this.applyLookup(lookup.lookupType, table);
          res = this.applyLookup(lookup.lookupType, table);
          if (res) {
            break;
          }
        }

        // because substitution may insert glyphs ahead of the current position
        // we need to skip them, otherwise this lookup will fire on its own output
        let inserted = glyphs.length - prevLen;
        for (let i = 0; i < inserted; i++) {
          this.glyphIterator.next();
        }

        this.glyphIterator.next();
      }
    }