Potential fix for code scanning alert no. 1894: Inconsistent lock sequence

To fix this problem, we should avoid locking on _syncLock in both methods when the instance method calls the static method. Because GetFont(Properties attributes) holds the lock while calling GetFont(...), which also tries to acquire the lock, there is a risk of deadlock or at least suboptimal locking. The best and most robust solution is to remove the lock (_syncLock) from one of these places to ensure the lock is only acquired once per operation. Since GetFont(Properties attributes) performs some parsing before calling the static method, and the core registry/caching logic is in the static method, it is preferable to only lock within the static method—meaning, remove the locking statement from the instance method (GetFont(Properties attributes)).

Specifically:

    Remove the lock (_syncLock) block from the GetFont(Properties attributes) method (lines 281 and 416).
    Ensure that thread safety still exists by keeping the lock in the static method.
    No new imports or dependencies are necessary.

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>

Author: VahidN

src/iTextSharp.LGPLv2.Core/iTextSharp/text/FontFactoryImp.cs

@@ -278,8 +278,8 @@ public Font GetFont(Properties attributes)
             throw new ArgumentNullException(nameof(attributes));
         }
 
-        lock (_syncLock)
-        {
+        // Removed lock (_syncLock) to prevent inconsistent locking sequence
+
             string fontname = null;
             var encoding = DefaultEncoding;
             var embedded = DefaultEmbedding;
@@ -413,7 +413,7 @@ public Font GetFont(Properties attributes)
             }
 
             return GetFont(fontname, encoding, embedded, size, style, color);
-        }
+
     }
 
     /// <summary>