نسمح برفع ملفات SVG في منتديات Maker، جزئيًا لأن أحد فئات مستخدمينا هم مستخدمو آلات النقش والقص بالليزر، وتُستخدم ملفات SVG بشكل شائع هناك. نود أن يتمكن الناس من رفعها؛ سواء لتنزيلها من قبل الآخرين أو لرؤيتها أثناء النقاش. وغالبًا ما يكون ذلك في سياق طلب المساعدة.
لسوء الحظ، تميل هذه الملفات إلى الظهور بحجم صغير جدًا، وأحيانًا بشكل يكاد يكون غير مرئي. الليلة، قام شخص ما برفع ملف SVG وتم تعيينه تلقائيًا بحجم 12×8 بكسل، وهو حجم صغير جدًا لدرجة أن الخطوط الملونة اختفت، وأصبح العرض أشبه بصورة دب قطبي في عاصفة ثلجية. (أنا مندهش من أن مشرف القسم لاحظ وجود ملف SVG هناك من الأساس.) لقد كانت هذه مشكلة شائعة بالنسبة لنا.
ربما يمكن للمستخدمين المخضرمين تعلم أنه يمكنهم، على سبيل المثال، تغيير 12x8 إلى 480x320 ليتمكنوا فعليًا من رؤية الصورة، لكن المستخدمين المخضرمين لا يحتاجون في الغالب إلى فعل ذلك؛ فمعظم الأشخاص الذين ينشرون ملفات SVG هم مبتدئون يبحثون عن مساعدة، وهم لا يعرفون هذه الغرابة في نظام Discourse.
ما الذي يجعل Discourse يختار تحديد حجم ملفات SVG إلى بضعة بكسلات فقط؟
إليك الاستعلام الذي تلقّيته من مشرف القسم، للمرجع:
تعديل: من ذلك الموضوع، سبب محتمل قد يفسر لماذا يؤثر هذا على المنتدى المعني أكثر من غيره:
آلات القص بالليزر الشائعة من نوع “K40” تتميز بسطح عمل بحجم 12 بوصة × 8 بوصات، وتعمل بدقة قدرها جزء من ألف من البوصة، وليس بالوحدات المترية، لذا فإن استخدام البوصات في ملفات SVG هذه يكون منطقيًا بشكل خاص، ولا يتعلق الأمر بـ “ينبغي على المستخدمين استخدام النظام المتري”.
من الواضح أن هذا تطلب السماح برفع ملفات SVG؛ وتذكرتي كانت أنني أضفت svg إلى إعداد authorized_extensions قبل حوالي عامين.
لقد رأيت بالفعل كود تنظيف ملفات SVG في Discourse. أرى أنها تُعرض هنا. نظرًا للقيمة التي تمثلها ملفات SVG لأحد المهام الأساسية لمنتديات Maker، بالإضافة إلى كيفية إدارتنا لمستخدمينا، فقد اخترنا عرضها عمدًا. عندما يواجه الناس مشاكل في قص/نقش ملفات SVG بالليزر، فإن القدرة على رؤية ملف SVG في سياق المحادثة تُعد مساعدة قيمة للفهم والتشخيص.
بما أنني تمكنت من عرض ملفات SVG هنا في صفحة الميتا أيضًا، فمن المفترض أنك اتخذت نفس القرار، رغم أنه بالطبع لسبب مختلف.
فقط للتأكد من أن النقطة التي أثارها سكورش أعلاه، وهي أن الأبعاد 12×8 بكسل ليست عشوائية على الأرجح، بل ناتجة على الأرجح عن عدم معالجة الوحدات في سمات العرض والارتفاع لعنصر svg: <svg ... width="12in" height="8in" ...> — لم أكن أدرك ذلك عندما نشرت السؤال لأول مرة.
أنت محق تمامًا. المكتبة التي نستخدمها لاستخراج أحجام الصور تأخذ فقط القيمة الصحيحة (العدد الصحيح) لسمات width وheight في ملفات SVG، ولا تحاول تحليل أي أنواع وحدات. سأقوم بالتدقيق وسأحاول التوصل إلى أنقى حل لهذه المشكلة.
لقد جربت عددًا من الملفات المشكلة باستخدام كل من ImageMagick وlibrsvg. يبدو أن ImageMagick يعتمد افتراضيًا على دقة 96 نقطة في البوصة (DPI)، بينما يعتمد librsvg افتراضيًا على 90. أعتقد أن أيًا منهما مقبول طالما أننا نختار قيمة افتراضية معقولة ونلتزم بها…
إما 90 أو 96 سيجعل ملفات SVG التي تحدد عرضها وارتفاعها بالبوصة والمليمتر على حد سواء ذات حجم معقول أكثر. حاليًا، تظهر ملفات SVG التي تحدد أبعادها بالمليمتر بمعدل مليمتر واحد لكل بكسل في المتصفح، مما يجعلها تظهر بحجم يقارب ثلث أو ربع الحجم الفعلي. في السابق، كنت أرفع كتفي وأقول: “حسناً، قابلة للتوسع على ما أظن…”، ولكن إذا أمكنك إضافة دعم لكل من البوصة والمليمتر بدقة افتراضية معقولة، فسيؤدي ذلك إلى تحسين عرض كليهما بشكل كبير.
إن HTML الخاص بالبريد الإلكتروني مجموعة مقيدة للغاية (ناهيك عن عدم اتساق تنفيذها؛ انظر إلى Litmus)، وأنتما تشيران إلى أن Discourse مُصمَّم للويب الحديث (مثل التمرير اللانهائي)، لذا لم أكن أدرك أن التمثيل الكامل في البريد الإلكتروني لكل ما يمكن تمثيله على الويب كان اعتباراً محورياً. هذه نقطة جديدة بالنسبة لي لفهمها. (يمكنني تخيّل أنه في ظل موارد لا نهائية، قد يتم تحويل SVG إلى PNG لإدراجه في البريد الإلكتروني، وهو ما سيكون أعلى دقة من الكثير من الحلول العشوائية المطلوبة لـ HTML في البريد الإلكتروني بشكل عام، ولكن مع عدم تفعيل SVG افتراضياً، يبدو ذلك أولوية منخفضة جداً…)
كان لدى @Neotinker أفكار حول استخدام onebox مع threejs لتضمين نماذج ثلاثية الأبعاد تفاعلية في محادثات Discourse المتعلقة بهذه النماذج؛ وهو شيء نود تفعيله لمنتديات المصنّعين (Maker Forums) إذا ما وُجدت يوماً كميزة. هل سيُعدّ اعتبار “عدم القدرة على العرض في البريد الإلكتروني” عائقاً أمام قبول مثل هذا العمل إذا قام هو أو شخص آخر بتنفيذه؟ (ألاحظ أن threejs تستخدم Discourse لمنتداها الخاص…)
أو إذا كان هذا يتعلق أكثر باتخاذ قرار أولويات حول مقدار الوقت الذي ترغب CDCK في إنفاقه على هذه المشكلة، فسأكون سعيداً بتوجيهي إلى الكود؛ لا أقصد إلقاء عبء هنا. لقد رأيتم في مساهماتي السابقة أنني لست خبيراً في Ruby أو RoR، لكنني مستعد لإدراجه في قائمة المهام التي أود الاطلاع عليها. (لقد نشرت هذا الموضوع أصلاً قبل أن ندرك أنه كان يتجاهل الوحدات ويفترض أن البكسل، لذا اعتقدت أنه قرار تصميمي، ولهذا السبب وضعته في Contribute > UX بدلاً من Contribute > Bug)
لقد أنشأت طلب سحب (pull request) يوم الجمعة بعد الظهر، والذي من المفترض أن يعالج مشكلة ظهور ملفات SVG بحجم صغير جدًا إذا كانت الأبعاد مُعبَّر عنها بالبوصات أو السنتيمترات أو المليمترات أو ما شابه ذلك.
طلب السحب في انتظار مراجعة الكود، لذا فهو غير متاح حاليًا، لكنه من المفترض أن يكون جاهزًا للعمل قريبًا.
