نسمح برفع ملفات 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 إذا ما وُجدت كميزة في المستقبل. هل اعتبار “لا يمكن عرض ذلك في البريد الإلكتروني” سيعيق قبول مثل هذا العمل إذا قام هو أو شخص آخر بتنفيذه؟ (ألاحظ أن threejs تستخدم Discourse لمنتداها الخاص…)
أو إذا كان هذا أكثر من مجرد أولوية لتحديد مقدار الوقت الذي ترغب CDCK في تخصيصه لهذه المشكلة، فسأكون سعيدًا للحصول على مؤشر إلى الكود؛ لا أقصد إلقاء عبء هنا. لقد رأيت في مساهماتي السابقة أنني لست خبيرًا في Ruby أو RoR، لكنني مستعد لوضع هذا في قائمة المهام الخاصة بي للنظر فيه. (لقد نشرت هذا الموضوع في الأصل قبل أن ندرك أنه كان يتجاهل الوحدات ويفترض البكسلات، لذا اعتقدت أنه قرار تصميم، وهو ما جعلني أضعه في ux بدلاً من bug)
لقد أنشأت طلب سحب (pull request) يوم الجمعة بعد الظهر، والذي من المفترض أن يعالج مشكلة ظهور ملفات SVG بحجم صغير جدًا إذا كانت الأبعاد مُعبَّر عنها بالبوصات أو السنتيمترات أو المليمترات أو ما شابه ذلك.
طلب السحب في انتظار مراجعة الكود، لذا فهو غير متاح حاليًا، لكنه من المفترض أن يكون جاهزًا للعمل قريبًا.
