الحفاظ على دقة الأعداد العشرية المحللة عند الحفظ في Delphi

يحتفظ PDFlibPas، مكتبة losLab PDF Developer Library، بالنص العشري الدقيق الذي حلله لكل عدد حقيقي في المستند ويعيد كتابة ذلك النص حرفياً كلما كانت القيمة لم تعدَّل قط. منذ v3.539.19 يتحكم إعداد SetPrecision بالأعداد التي تنشئها المكتبة أو تحررها وحدها، فلن يقرّب حفظ عادي وتحميل /Gamma لـ CalRGB من 2.22221 إلى 2.2222 فيزيح ألوان صفحة لم يلمسها أحد. التغيير صغير في الكود وكبير فيما يقوله عن المحللات: القيمة التي تفككها والنص الحرفي الذي تصدره شيئان مختلفان، وجولة ذهاب وإياب عبر Double ليست تحويلة محافظة على الهوية

لماذا زاحم حفظ لم يغيّر شيئاً ألوان الصفحة؟

لأن وسائط فضاء اللون كان يعاد تنسيقها، لا الصورة. الملف الذي كشف هذا مستند مكتبي من 35 صفحة في مدونة الانحدار المحلية، بصورة ترويسة معاد استخدامها في كل صفحة. حمّله واحفظه مباشرة أنتجت تدفقات صور مطابقة بايتاً ببايت للمدخل، وبلّغت مقارنة بصمات التدفقات أن المستند لم يتغير. خالفت المقارنة المصوّرة: كل واحدة من الصفحات الـ 35 أظهرت فروق بكسل في الترويسة، ولا في مكان آخر

ترسم صورة الترويسة عبر فضاء ألوان CalRGB، الذي يعرّفه ISO 32000-1 §8.6.5.3 بـ /WhitePoint ومصفوفة /Gamma اختيارية من ثلاثة عناصر ومصفوفة /Matrix اختيارية من تسعة عناصر. تلك المصفوفات كائنات عددية عادية في قاموس فضاء اللون. خزّنت TPDFNumeric كل واحدة منها كـ Double ولا شيء غير ذلك، وصاغت TPDFNumeric.Output ذلك الـ Double عبر PDFPrecNum الذي يأتي افتراضياً بأربعة مواضع عشرية. فذهبت /Gamma من 2.22221 إلى 2.2222، وذهب إدخال مصفوفة من 0.71519 إلى 0.7152، وأنتج العارض بأمانة ألواناً مختلفة قليلاً من معايرة مختلفة قليلاً. بايتات الصورة كانت بريئة؛ الأعداد حولها لم تكن كذلك. والجزء المقلق هو مدى خفاء ذلك. مقارنة بايتات التدفق المفكوك لا تراه، لأن الأعداد تعيش في قاموس لا في تدفق. ومقارنة حمولات المرفقات لا تراه. وحتى فرق المراجعات الموصوف في مقالة مستويات التعديل يبصم جسم كائن منطبَع، فتُبصم كلتا المراجعتين إلى القيمة نفسها ويبلّغ الفرق عنهما كمتطابقتين. لم يمسكه إلا العرض، ولهذا تصرّ أساس مدونة المستندات كل صفحة بدل الاكتفاء بالفحوص البنيوية

القيمة التي حللتها ليست الحرفية التي ينبغي أن تكتب

العدد الحقيقي في PDF سلسلة عشرية، و ISO 32000-1 §7.3.3 صريح في أنها سلسلة عشرية فحسب: لا تدوين جذري ولا صيغة أسّية. ثم يسرد الملحق C الدقة المتوقع أن تحترمها التنفيذات، نحو خمسة أرقام عشرية معنوية في الجزء الكسري. ودقة إخراج افتراضية من أربعة تحت ذلك أصلاً، وقبل v3.539.34 كان الأمر يسوء قرب الصفر: كانت PLDoubleToStr تحجّم القيمة وتقرّبها إلى عدد صحيح وتصدر 0 حين يكون الناتج صفراً، فإدخال مصفوفة مثل -0.000012345 لم يفقد رقماً، بل كان يختفي كلياً. ومنذ PDFlibPas v3.539.34 تكتب PLDoubleToStr القيمة غير الصفرية الأصغر من خطوة الدقة بأرقامها المعنوية بدل 0، فلم يعد معامل تحجيم ضئيل يتحول إلى مصفوفة شاذة (singular matrix)؛ والمقادير الوحيدة التي ما زالت تنهار إلى 0 هي التي تقل عن حد الخمسة عشر موضعاً في جدول البحث الخاص بها

رفع الافتراضي لا يفعل شيئاً سوى تحريك الهاوية. الإصلاح هو التوقف عن التظاهر بأن Double هو العدد. عندما يتعرف المميّز في TPDFStructure.Decode على حقيقي قياسي، أي أن الرمز يحوي نقطة عشرية ولا يحمل مؤشر أس، يخزّن النص المصدر في حقل FOriginalText الجديد إلى جانب القيمة المحوّلة. ثم تفضّل Output ذلك النص ولا تعود إلى التنسيق إلا إذا لم يوجد ما يُفضَّل

// Lib/PDFlibStruct.pas — الإصلاح كله في جهة الإخراج
Function TPDFNumeric.Output: AnsiString;
Begin
  If FOriginalText<> '' Then
    Result:= FOriginalText
  Else
    Result:= PLDoubleToStr(FValue, Owner.PDFPrecNum);
End;

Procedure TPDFNumeric.SetTo(Const Value: Double);
Begin
  FOriginalText:= '';   // الرقم المعدَّل رقم جديد
  FValue:= Value;
  FChanged:= True;
End;

حدّان مقصودان. الأعداد الصحيحة لا تُحفظ، لأن تنسيق الأعداد الصحيحة بلا خسارة أصلاً. وصيغ الأس مثل 6.02E23 تتسامح معها في المدخل من أجل منتجين معيبين لكنها لا تُحفظ في المخرج، لأن إعادة كتابتها تُخلّد صياغة يمنعها §7.3.3؛ فهي تمر بالمنسّق مثل أي عدد ولّدته المكتبة. كما يطبق المميّز إصلاحه الأدنى المعتاد قبل تخزين النص، فيبقى الحرفي النقطي الابتدائي مثل .5 كـ 0.5 والحرفي النقطي الختامي مثل 5. كـ 5.0. وكلاهما العدد نفسه عند كل قارئ ويقبله أوسع بكثير

ماذا يضمن SetPrecision بعد v3.539.19؟

يتحكم TPDFlib.SetPrecision الآن في المواضع العشرية للأعداد التي تنتجها المكتبة نفسها: القيم المسحوبة عبر الرسّام، والأعداد المنشأة من Double كما عبر NewNumeric، وأي قيمة محللة عُدّلت لاحقاً بـ SetTo. ولاحظ أن النص المفكوك عبر واجهة الكائنات، مثل حرفي ممرر إلى SetObjectFromString، يمر بالمميّز نفسه ويُحفظ بالطريقة نفسها. العدد العشري المحلل الذي لم يُعدَّل يبقي دقة مدخله أياً كان الإعداد، وتغيير الإعداد بعد التحميل لا يلمسه بأثر رجعي. حُدّث إدخال مرجع SetPrecision في الإصدار نفسه ليقول هذا بالضبط، لأن الصياغة القديمة توحي بأن الإعداد ينطبق على كل عدد في الملف

والمسح يجري في SetTo لا يُشتق من علم Changed، وهذا التمييز مهم. يعيد خط أنابيب الحفظ تصفير Changed على الكائنات بعد كتابتها، ففحص من النمط "أصدر النص الأصلي إلا إذا تغير" سيبدأ بإصدار نص قديم لقيمة عُدّلت ثم حُفظت ثم عُدّلت ثانية في نفس الجلسة. ربط النص الأصلي بالإسناد نفسه يجعل اختلاف الاثنين مستحيلاً. ويثبّت اختبار الانحدار كل سلوك من هذه السلوكيات بالقيم من الملف الأصلي

uses
  PDFlibStruct;

var
  Structure: TPDFStructure;
  Values: TPDFArray;
  Number: TPDFNumeric;
begin
  Structure := TPDFStructure.Create;
  try
    Structure.PDFPrecNum := 4;
    Values := TPDFArray(Structure.Decode('[2.22221 0.71519 -0.000012345 1 0.12567]'));
    // مدخل بلا تحرير ينجو حرفياً، بما في ذلك القيمة التي
    // كان التنسيق بأربعة مواضع ينهار إلى 0 قبل v3.539.34
    Assert(Values.Output = '[ 2.22221 0.71519 -0.000012345 1 0.12567 ]');

    // تعديل يرمي النص الأصلي ويتبع PDFPrecNum
    Number := TPDFNumeric(Values.Item[0]);
    Number.SetTo(0.123456);
    Assert(Number.Output = '0.1235');
    Assert(Structure.NewNumeric(0.123456).Output = '0.1235');

    // خفض الدقة لاحقاً لا يبلغ المدخل غير المعدَّل
    Structure.PDFPrecNum := 2;
    Assert(TPDFNumeric(Values.Item[1]).Output = '0.71519');
  finally
    Structure.Free;
  end;
end;

متى ما زال نموذج المحتوى يطبّع الأعداد؟

فقط عندما يكون المخرج القياسي هو غاية العملية نفسها. منذ PDFlibPas v3.539.34 تأخذ TPDFContentProgram.CanonicalNumbers القيمة الافتراضية False، فيحتفظ نموذج المحتوى القابل للتحرير — وهو نفسه الذي بُني عليه متتبع حالة الرسوميات — بالنص المصدر لكل معامل عددي يحلله. ومن ثمّ لا تغيّر تحريرات الصفحة التي تعيد كتابة طبقة محتوى، مثل ScalePage وTransformPageElement وDeletePageElement وRedactRegion وConvertTextToPaths وبرنامج من ParsePageContentLayer يُكتب مجدداً بـ WritePageContentLayer، إلا المعاملات التي لمسها التحرير، بدل تقريب الطبقة كلها إلى أربعة مواضع عشرية كما كانت تفعل قبل ذلك الإصدار. والصيغة القياسية ما زال لها عمل: وجود NormalizeContentStreams ومُحسِّن المحتوى وقت الحفظ هو لإنتاج مخرج مستقر قابل للمقارنة من مدخل عشوائي، ولو احتفظت معاملاتها المحللة بالنص الأصلي لصدر تتابع معاملات مثل 0.50000 0 0 RG بشكل مختلف عن 0.5 0 0 RG وانجرفت كل مقارنة هابطة مع عادات تنسيق المنتج

إذن الأعداد القياسية اختيارية وقت التحليل وإلزامية فقط للمعاملات التي يمررها المستدعي. مع CanonicalNumbers مضبوطة على True — وهو كيف يحلل NormalizeContentStreams والمُحسِّن — تجري NormalizeContentNumbers على كل معامل عندما يدفعه المحلل؛ وبغضّ النظر عن العلم، تجري داخل SetOperand حين يُفك مصدر قادم من المستدعي. وتتكرر داخل المصفوفات والقواميس حتى تغطى أنماط الشرطات ومصفوفات TJ وقواميس خصائص المحتوى الموسوم. استدعاء SetTo(AsDouble) على كل عدد يكفي، لأنه بالضبط العملية التي تمسح النص. والقارئ الوحيد لهذا العلم هو Parse، لذا يجب ضبطه قبل التحليل؛ أما البرنامج الذي يعيده ParsePageContentLayer فمحلَّل سلفاً، وتحويله إلى أعداد قياسية يتطلب Parse(Emit) بعد ضبط العلم. أما بيانات الصور المضمّنة الخام فتُترك على حالها، كما كانت دائماً

// Lib/PDFlibContentModel.pas — نموذج المحتوى يفي بعقده
Procedure NormalizeContentNumbers(Obj: TPDFObject);
Var
  K: Integer;
Begin
  If Obj is TPDFNumeric Then
    TPDFNumeric(Obj).SetTo(TPDFNumeric(Obj).AsDouble)
  Else If Obj is TPDFArray Then
    For K:= 0 To TPDFArray(Obj).Count- 1 Do
      NormalizeContentNumbers(TPDFArray(Obj).Item[K])
  Else If Obj is TPDFDictionary Then
    For K:= 0 To TPDFDictionary(Obj).Count- 1 Do
      NormalizeContentNumbers(TPDFDictionary(Obj).Entry[K].Value);
End;

القاعدة العملية للمستدعين بسيطة إذن. LoadFromFile عادية يتبعها SaveToFile تُبقي تدفقات المحتوى غير الملموسة والأعداد القاموسية غير الملموسة كما كانت. ومنذ v3.539.34 تحتفظ الصفحة التي حُرّرت عبر نموذج المحتوى أيضاً بالنص الأصلي لكل معامل لم يغيّره التحرير. وتخرج قياسية بالتصميم هذه الحالات وحدها: NormalizeContentStreams، ومُحسِّن المحتوى وقت الحفظ الذي يجري عند ضغط المحتوى، والبرنامج المحلَّل بعد ضبط CanonicalNumbers على True، وبقية المستند ما زال محفوظاً. هذه طلبات مختلفة، وهي الآن تفعل أشياء مختلفة

ماذا يكلف، وأين تتوقف الضمانة؟

يحمل كل TPDFNumeric الآن مرجع AnsiString إضافياً واحداً، ويُبقي كل عدد عشري محلل نصه المصدر حياً على مدى عمر الكائن. في مستند بملايين الأعداد الحقيقية تلك ذاكرة حقيقية، ويجب إدراجها في أي قياس للمستندات الكبيرة لا الرف عنها بيدين. والضمانة محدودة النطاق بمستند العدد نفسه: نسخ الكائنات بين المستندات أو إعادة بناء القيم عبر واجهة الكائنات ينتج أعداداً جديدة تتبع دقة الإخراج مثل أي عدد جديد. ويستحق أن نكون دقيقين فيما يدّعيه الإصدار وما لا يدّعيه. حفظ مستند غير ملموس وتحميله يحفظ الآن أعداد المعايرة التي يستهلكها العارض فعلاً، وهي الخاصية التي يفحصها أساس المدونة. ولا يدّعي مخرجاً متطابقاً بايتاً ببايت، فذلك يعتمد أيضاً على ترقيم الكائنات وضغط التدفقات ومعرف المقطع الختامي المذكور في مقالة معرف PDF الحتمي. ولا يجعل فرق البصمة يرى فروق التقريب في ملفات أنتجها برمجيا آخرون، لأنها ما زالت تبصم الجسم المنطبَع. والدرس يتعمم إلى ما وراء CalRGB بكثير: حين يحتفظ محلل بالقيمة المحوّلة وحدها يصير كل حفظ تحريراً، والطريق الوحيد للانتباه هو النظر إلى النتيجة المصوّرة. معالجة الأعداد ودلالات SetPrecision موثقة على صفحة منتج losLab PDF Developer Library