مدونة طارق الغوراني

Pattern Geometry Commons: من الزخرفة إلى بنية دلالية مفتوحة للأنماط الهندسية

13 دقائق للقراءة

Pattern Geometry Commons:

من الزخرفة إلى بنية دلالية مفتوحة للأنماط الهندسية

أطلقت مؤخرًا مشروعًا مفتوح المصدر باسم Pattern Geometry Commons، وهو محاولة لبناء طبقة مشتركة ومفتوحة لوصف الأنماط الهندسية ثنائية الأبعاد، ليس بوصفها رسومات جميلة فقط، بل بوصفها أنظمة قابلة للفهم، التحقق، التحويل، وإعادة الاستخدام.

الفكرة الأساسية بسيطة في ظاهرها: بدل أن نبدأ من السؤال: “كيف أرسم هذا الشكل؟”، يبدأ المشروع من سؤال أعمق: ماذا يعني هذا النمط؟

هل هو حقل متكرر؟ هل هو ترتيب شعاعي؟ هل يقوم على شبكة سداسية أم مربعة؟ هل العنصر الأساسي فيه نجمة، وردة، مضلع، أم شكل مخصص؟ هل الهدف منه العرض على الويب، أم التحويل إلى CAD، أم التصنيع بالليزر أو CNC؟

من هنا جاء المشروع: طبقة وسيطة تفصل بين معنى النمط وطريقة إنتاجه هندسيًا.

لماذا هذا المشروع؟

عند العمل مع الأنماط الهندسية، خصوصًا الأنماط الإسلامية، الزخارف المعمارية، الشبكات التجريدية، أو التصاميم القابلة للتصنيع، توجد عادة مشكلتان:

الأولى أن كثيرًا من الأدوات تعرف كيف ترسم خطوطًا ومسارات وإحداثيات، لكنها لا تعرف ماذا تمثّل هذه الخطوط. بالنسبة لها، النجمة السداسية أو الوردة الهندسية أو الشبكة المعمارية ليست “نمطًا” له معنى، بل مجرد نقاط وخطوط ومسارات.

الثانية أن كل أداة تحتفظ بالمنطق داخلها. إذا بنيت نمطًا داخل محرر SVG، يبقى مرتبطًا بطريقة SVG. وإذا بنيته داخل Maker.js، يبقى مرتبطًا بمنطق Maker.js. وإذا احتجته في CAD أو DXF، غالبًا تحتاج إلى إعادة تفكير أو تحويل يدوي أو كتابة كود جديد.

Pattern Geometry Commons يحاول معالجة هذه المشكلة عبر طبقة وسيطة، يمكن أن نسميها: Semantic Intermediate Representation، أو اختصارًا Semantic IR.

أي أن المشروع لا يبدأ من الرسم النهائي، بل من وصف دلالي للنمط:

  • نوع النمط.
  • عائلة العناصر داخله.
  • نظام الترتيب أو الشبكة.
  • نمط التناظر.
  • طريقة الرندر المطلوبة.
  • الصيغة النهائية المطلوبة.

ثم تأتي طبقة أخرى، هي الـ Backend، لتقرر كيف تحوّل هذا الوصف إلى SVG أو Maker.js أو DXF.

ما هو Pattern Geometry Commons؟

Pattern Geometry Commons هو مشروع JavaScript مفتوح المصدر يقدّم:

  1. مواصفة IR لوصف الأنماط الهندسية ثنائية الأبعاد.
  2. JSON Schema للتحقق من صحة ملفات الأنماط.
  3. Validator للتأكد من أن أي وصف هندسي يلتزم بالمواصفة.
  4. Compiler يحوّل الوصف الدلالي إلى مخرجات فعلية.
  5. Backends لإنتاج SVG وMaker.js وDXF.
  6. CLI لاستخدام المشروع من سطر الأوامر.
  7. API لاستخدامه برمجيًا داخل مشاريع JavaScript.
  8. أمثلة جاهزة لأنماط إسلامية، تجريدية، وتصنيعية.
  9. بنية قابلة للتوسيع تسمح بإضافة backends جديدة لاحقًا.

المشروع منشور على GitHub وتحت رخصة Apache-2.0، ومتاح كحزمة npm باسم:

@tarek-g/pattern-geometry-commons

ما الذي لا يحاول المشروع أن يكونه؟

من المهم توضيح الحدود منذ البداية.

هذا المشروع ليس مكتبة هندسية تقليدية لحساب كل الإحداثيات بنفسه. وليس محرك رسم كاملًا مثل أدوات التصميم. وليس بديلًا عن Maker.js أو SVG أو CAD.

الأدق أنه طبقة تقع قبل كل ذلك.

هو لا يقول: “ارسم هذا الخط من النقطة A إلى النقطة B”.

بل يقول: “لدينا نمط من نوع repeating-field، مبني على شبكة سداسية، يحتوي على motif من عائلة star، بعدد أضلاع معين، وبنمط تناظر محدد، ونريد إخراجه كـ SVG أو DXF”.

بعدها يأتي الـ backend ليحوّل هذه الدلالة إلى هندسة فعلية.

هذا الفصل بين المعنى والرسم هو قلب المشروع.

الفكرة المعمارية: من المعنى إلى الشكل

يمكن تبسيط المعمارية بهذا الشكل:

flowchart TD
  ir["Pattern IR<br/>الوصف الدلالي للنمط"]
  validator["Validator<br/>التحقق من المواصفة"]
  compiler["Compiler<br/>توجيه عملية التحويل"]
  backend["Backend<br/>إنتاج الهندسة النهائية"]
  output["Output<br/>SVG / Maker.js JSON / Maker.js SVG / DXF"]

  ir --> validator --> compiler --> backend --> output

الـ IR هو ملف JSON يصف النمط.

الـ Validator يتحقق من أن الملف صحيح ومتوافق مع المواصفة.

الـ Compiler يقرأ الـ IR ويوجه العملية إلى الـ backend المناسب.

الـ Backend ينتج المخرجات النهائية: SVG للويب، أو Maker.js للتعامل الهندسي، أو DXF للتصنيع وأدوات CAD.

بهذه الطريقة لا يبقى النمط حبيس أداة واحدة. نفس الوصف الدلالي يمكن أن ينتج أكثر من صيغة.

لماذا كلمة “Commons”؟

كلمة Commons هنا مهمة.

الفكرة ليست فقط بناء أداة خاصة بمشروع واحد، بل تحويل جزء من بنية بحثية وعملية إلى مورد مشترك يمكن للآخرين استخدامه والبناء فوقه.

الأنماط الهندسية ليست مجرد زخارف. هي مجال يتقاطع فيه الفن، الرياضيات، العمارة، البرمجة، الحرف، التصنيع الرقمي، والتاريخ البصري. لكن الأدوات التي تتعامل معها غالبًا تكون إما مغلقة، أو مرتبطة بمنطق تطبيق واحد، أو تركز على الناتج البصري فقط.

المشروع يحاول فتح طبقة أعمق: طبقة الوصف.

إذا أصبح لدينا تمثيل مشترك للأنماط، يمكن لاحقًا بناء أدوات كثيرة فوقه:

  • معارض رقمية تشرح بنية النمط.
  • مولدات زخارف قابلة للتخصيص.
  • أدوات تعليمية لفهم التناظر والشبكات.
  • واجهات تصميم تنتج SVG أو DXF.
  • أرشيفات ثقافية توثق الأنماط ومصادرها.
  • أدوات تصنيع رقمية تعتمد على وصف واضح وقابل للتحقق.

ما هو pg-ir-v0؟

الإصدار الحالي من مواصفة التمثيل الوسيط اسمه:

pg-ir-v0

وهو الإصدار الأول المستقر من Pattern Geometry IR داخل المشروع.

كل ملف IR يجب أن يعلن إصداره بوضوح، لأن وجود نسخة محددة من المواصفة يجعل التحقق، التطوير، والتوافق المستقبلي أسهل.

مثال مبسط:

{
  "version": "pg-ir-v0",
  "pattern": {
    "id": "my-hex-star"
  },
  "geometry": {
    "tiling": {
      "type": "regular",
      "id": "6.6.6",
      "cellSize": 60
    },
    "motifs": [
      {
        "id": "star-1",
        "family": "star",
        "parameters": {
          "sides": 6,
          "skip": 1,
          "rotation": 0
        },
        "renderMode": "line"
      }
    ]
  }
}

هذا المثال لا يصف مجرد شكل عشوائي، بل يقول إن لدينا نمطًا يقوم على شبكة سداسية، وفيه motif من عائلة النجوم، وله معاملات واضحة.

التصنيفات الأساسية داخل IR

المشروع يتيح تصنيف الأنماط بعدة طرق، من بينها:

1. نوع النمط

يمكن للنمط أن يكون مثلًا:

  • repeating-field: حقل متكرر منتظم.
  • frieze: شريط زخرفي أو حدودي.
  • radial: ترتيب شعاعي حول مركز.
  • freeform: تخطيط حر.
  • lattice: شبكة هيكلية.

هذه التصنيفات تساعد على فهم البنية العامة للنمط قبل إنتاجه.

2. عائلة العنصر Motif Family

العنصر الأساسي داخل النمط يمكن أن يكون:

  • star: نجمة.
  • rosette: وردة أو زهرة هندسية.
  • polygon: مضلع منتظم.
  • simple: شكل بسيط مثل دائرة.
  • custom: عنصر مخصص حسب backend.
  • irregular: شكل غير منتظم.

هذه الطبقة مهمة لأن النمط الهندسي لا يُفهم فقط من إحداثياته، بل من نوع العناصر التي يتكون منها.

3. نظام الترتيب Tiling

المشروع يدعم ترتيبات مختلفة، مثل:

  • 6.6.6: شبكة سداسية.
  • 4.4.4.4: شبكة مربعة.
  • 4.8.8: مربع مع مثمنين.
  • 3.4.6.4: مثلث، مربع، مسدس، مربع.
  • diagonal-grid: شبكة قطرية.
  • lattice: شبكة هيكلية.
  • none: بدون ترتيب محدد.

هذه القيم تسمح بوصف العلاقات المكانية داخل النمط دون القفز مباشرة إلى تفاصيل الرسم.

4. أسلوب الرسم Render Mode

يمكن للـ IR أن يحدد طريقة الرندر المطلوبة، مثل:

  • line: رسم بالخطوط.
  • fill: تعبئة.
  • interlace: تداخل بصري من نوع فوق/تحت.
  • band: أشرطة.
  • none: بيانات فقط دون رسم.

هذا يفتح الباب أمام استخدامات مختلفة لنفس النمط: عرض بصري، دراسة بنيوية، أو تصنيع.

الـ Backends: لماذا نحتاج أكثر من مخرج؟

إحدى نقاط القوة في المشروع أنه لا يربط النمط بمخرج واحد.

حاليًا توجد backends لإنتاج:

  • SVG للعرض على الويب والمتصفح.
  • Maker.js JSON للتعامل مع نموذج هندسي قابل للمعالجة.
  • Maker.js SVG لمن يريد الاستفادة من Maker.js مع مخرج SVG.
  • DXF للاستخدام في CAD والتصنيع الرقمي.

الفكرة أن الـ Core لا ينشغل بتفاصيل الإحداثيات النهائية لكل صيغة. هو يحتفظ بالدلالة والتحقق والتوجيه. أما الـ backend فيتولى تحويل ذلك إلى هندسة منخفضة المستوى.

هذا يعني أن إضافة backend جديد في المستقبل لا تتطلب إعادة اختراع المشروع كله. يمكن تسجيل backend مخصص يتبع عقدًا واضحًا.

مثال برمجي مختصر:

// يوضح هذا المثال كيفية تسجيل backend مخصص داخل المشروع ثم استخدامه كصيغة إخراج جديدة.
import { registerBackend, compileIr } from '@tarek-g/pattern-geometry-commons';
 
registerBackend('my-format', (ir, options) => {
  return {
    result: 'custom output',
    meta: {
      format: 'my-format',
      patternId: ir.pattern.id
    }
  };
});
 
const output = await compileIr(ir, { format: 'my-format' });

استخدام المشروع من سطر الأوامر

يمكن تثبيت الحزمة عبر npm:

# يثبت هذا الأمر حزمة Pattern Geometry Commons لاستخدامها داخل مشروع JavaScript.
npm install @tarek-g/pattern-geometry-commons

بعد ذلك يمكن التحقق من ملف IR:

# يتحقق هذا الأمر من أن ملف pattern.json يلتزم بمواصفة pg-ir-v0.
node scripts/validate.mjs pattern.json

ويمكن تجميعه إلى SVG:

# يحوّل هذا الأمر ملف IR إلى SVG ويحفظ الناتج في output.svg.
node scripts/compile.mjs pattern.json --format svg --out output.svg

أو إلى DXF لاستخدامه في CAD أو التصنيع:

# يحوّل هذا الأمر ملف IR إلى DXF مناسب للتجربة داخل أدوات CAD مثل LibreCAD أو AutoCAD.
node scripts/compile.mjs pattern.json --format makerjs-dxf --out output.dxf

كما توجد أوامر اختبار للتحقق من الأمثلة، compiler، backends، وحدود الحزمة.

استخدام المشروع برمجيًا

يمكن استخدام المشروع كـ API داخل JavaScript:

// يوضح هذا المثال طريقة التحقق من IR ثم تجميعه إلى SVG داخل تطبيق JavaScript.
import { validateIr, compileIr } from '@tarek-g/pattern-geometry-commons';
 
const validation = validateIr(ir);
 
if (!validation.valid) {
  console.error(validation.errors);
} else {
  const { result, meta } = await compileIr(ir, { format: 'svg' });
  console.log(result);
  console.log(meta);
}

وتوجد دوال عامة متعددة، منها:

  • validateIr(ir) للتحقق من صحة IR.
  • compileIr(ir, opts) للتجميع إلى صيغة محددة.
  • loadSchema() لتحميل JSON Schema.
  • registerBackend(format, fn) لتسجيل backend مخصص.
  • listFormats() لعرض الصيغ المتاحة.
  • listExamples() لعرض الأمثلة.
  • loadExample(path) لتحميل مثال.
  • compileSvg(ir, opts) لإنتاج SVG.
  • compileMakerJsDxf(ir, opts) لإنتاج DXF.

أمثلة المشروع

يتضمن المشروع مجموعة أمثلة موزعة على عدة فئات.

أنماط إسلامية

منها:

  • حقل نجمة سداسية.
  • نجمة ثمانية مبنية على ترتيب مربع/مثمن.
  • نجمة عشرية.
  • وردة هندسية داخل حقل سداسي.

هذه الأمثلة مهمة لأنها تربط المشروع بمجال بصري غني: الزخارف الإسلامية والأنماط الهندسية التاريخية.

أنماط تجريدية

مثل:

  • شبكة مربعة بسيطة.
  • ترتيب شعاعي.
  • خطوط متداخلة من نوع Moiré.

هذه الأمثلة تبيّن أن المشروع لا يقتصر على الزخرفة الإسلامية فقط، بل يمكن استخدامه لوصف أنظمة بصرية عامة.

أنماط للتصنيع

مثل:

  • شاشة مثقبة CNC.
  • لوحة laser-cut.
  • شبكة معمارية يمكن التفكير بها في سياق water-jet أو واجهات معمارية.

هذه الفئة مهمة لأنها تنقل المشروع من العرض البصري إلى التصنيع الرقمي.

مثال عملي: من وصف دلالي إلى SVG

لنفترض أننا نريد إنشاء نمط نجمة سداسية.

نبدأ بملف IR يصف النمط: الإصدار، هوية النمط، الشبكة، العنصر، ومعاملاته. بعد ذلك نتحقق من الملف. إذا كان صحيحًا، نجمعه إلى SVG.

الخطوات ستكون تقريبًا هكذا:

# يتحقق هذا الأمر من سلامة ملف IR قبل محاولة تحويله إلى أي صيغة إخراج.
node scripts/validate.mjs my-star.json

إذا نجح التحقق، نجمعه:

# يحوّل هذا الأمر النمط الموصوف في my-star.json إلى ملف SVG قابل للعرض في المتصفح.
node scripts/compile.mjs my-star.json --format svg --out my-star.svg

وإذا أردنا استخدامه في CAD:

# يحوّل هذا الأمر نفس النمط إلى DXF، أي أن الوصف نفسه يمكن أن يخدم مسار تصنيع أو CAD.
node scripts/compile.mjs my-star.json --format makerjs-dxf --out my-star.dxf

النقطة المهمة هنا أن الملف الأصلي لم يتغير. الذي تغير هو الـ backend والمخرج.

لماذا هذا مهم للأنماط الهندسية الإسلامية؟

الأنماط الهندسية الإسلامية غالبًا تُعرض بوصفها زخارف نهائية. نرى الصورة، لكن لا نرى دائمًا البنية التي صنعتها.

في العمل البحثي أو المتحفي أو التعليمي، هذا غير كافٍ. نحتاج أن نعرف:

  • ما الشبكة التي يقوم عليها النمط؟
  • ما العنصر الأساسي؟
  • كيف يتكرر؟
  • ما علاقة التناظر بالشكل النهائي؟
  • هل يمكن إنتاجه بأكثر من صيغة؟
  • هل يمكن مقارنته بنمط آخر؟
  • هل يمكن ربطه بمصدر أو تقليد أو استخدام معماري؟

هذا المشروع لا يحل كل هذه الأسئلة وحده، لكنه يضع طبقة تقنية يمكن البناء عليها.

بدل أن تبقى الزخرفة صورة، يمكن أن تصبح بيانات دلالية قابلة للتحقق.

وهذا مهم جدًا لأي مشروع أكبر يريد بناء أطلس للأنماط، أو أرشيف بصري، أو معرض رقمي، أو أداة تعليمية تشرح كيف تعمل الأنماط بدل الاكتفاء بعرضها.

العلاقة مع مشاريعي الأخرى

بالنسبة لي، هذا المشروع ليس منفصلًا عن اهتمامي الأوسع ببناء أنظمة معرفة رقمية.

في مشاريع أخرى أتعامل مع النصوص، المفاهيم، المقالات، الشخصيات، العلاقات، والخرائط الدلالية. هنا أنتقل إلى مجال بصري وهندسي، لكن السؤال العميق مشابه:

كيف نحول شيئًا معقدًا إلى بنية قابلة للفهم والتنقل وإعادة الاستخدام؟

في النصوص، قد يكون لدينا مقالات ومفاهيم واقتباسات وعلاقات.

في الأنماط الهندسية، لدينا شبكات، تناظرات، عناصر، تكرارات، ومخرجات.

في الحالتين، الفكرة ليست فقط “إنتاج محتوى”، بل بناء طبقة تجعل المحتوى قابلًا للتحليل، الربط، والنشر.

من هنا يمكن فهم Pattern Geometry Commons كجزء من اهتمام أكبر بـ أنظمة المعرفة المفتوحة: أن نجعل البنى المعقدة، سواء كانت نصية أو بصرية، قابلة للفهرسة، الفهم، والتحويل.

لماذا فصل المعنى عن الإخراج مهم؟

لأن الخلط بين المعنى والإخراج يجعل المشاريع هشة.

إذا كان النمط مجرد SVG، فأنت تملك الشكل النهائي، لكنك لا تعرف بالضرورة كيف تعيد توليده أو تغييره أو مقارنته.

إذا كان النمط مجرد DXF، فهو مفيد للتصنيع، لكنه ليس بالضرورة مناسبًا للشرح أو التعليم أو العرض التفاعلي.

إذا كان النمط كودًا داخل مكتبة معينة، فهو مرتبط بتلك المكتبة.

أما عندما يكون لديك IR واضح، فأنت تملك وصفًا وسيطًا يمكن أن يعيش بين الأدوات.

هذا يشبه ما يحدث في compilers: هناك لغة عالية المستوى، ثم تمثيل وسيط، ثم مخرجات متعددة. هنا أحاول تطبيق الفكرة على الأنماط الهندسية.

أين يمكن استخدام المشروع؟

يمكن استخدام Pattern Geometry Commons في عدة سياقات:

1. الويب والتصميم التفاعلي

يمكن إنتاج SVG للعرض داخل المتصفح، واستخدامه في واجهات تفاعلية، معارض رقمية، أدوات تعليمية، أو مولدات أنماط.

2. CAD والتصنيع

من خلال Maker.js وDXF، يمكن التفكير في مسارات نحو laser cutting، CNC، water-jet، أو نماذج معمارية.

3. التعليم

يمكن استخدام المشروع لشرح العلاقة بين الشبكات، التناظر، والعناصر البصرية. بدل أن يرى الطالب الشكل النهائي فقط، يمكنه رؤية البنية التي تقف خلفه.

4. الأرشفة الثقافية

يمكن لاحقًا ربط الأنماط بمصادر، مواقع، صور، مراجع، أو تواريخ، بحيث لا تكون مجرد رسومات معزولة.

5. البحث البصري

وجود تمثيل دلالي يفتح الباب أمام المقارنة بين الأنماط: أيها يستخدم شبكة سداسية؟ أيها يعتمد على ترتيب شعاعي؟ أيها يستخدم rosette؟ أيها قابل للتحويل إلى DXF؟

حدود النسخة الحالية

المشروع في مرحلته الأولى، لذلك من المهم عدم تضخيمه.

النسخة الحالية تؤسس البنية الأساسية:

  • مواصفة IR.
  • JSON Schema.
  • تحقق.
  • Compiler.
  • Backends أساسية.
  • أمثلة.
  • CLI.
  • API.
  • اختبارات.
  • رخصة مفتوحة.

لكن هناك أشياء ليست ضمن النطاق الحالي أو تحتاج إلى تطوير لاحق، مثل:

  • محرر بصري كامل.
  • نظام style maps متقدم.
  • حفظ حالة workspace كاملة.
  • دعم PDF كـ backend مستقر.
  • نمذجة تفصيلية جدًا لكل أشكال interlace.
  • ربط الأنماط بمصادر تاريخية أو أرشيفية.
  • واجهة مستخدم نهائية لغير المطورين.

وهذا مقصود. المشروع يبدأ من الطبقة الصلبة: المواصفة، التحقق، والتحويل.

ما الذي أنجزته فعليًا؟

النسخة الحالية تتضمن بنية مشروع كاملة تقريبًا:

  • ملف README.
  • رخصة Apache-2.0.
  • ملف NOTICE لحقوق النشر والإسناد.
  • package.json للحزمة.
  • مجلد spec/ وفيه JSON Schema.
  • مجلد src/ وفيه الكود الأساسي.
  • مجلد backends/ وفيه SVG وMaker.js.
  • مجلد examples/ وفيه أمثلة متعددة.
  • مجلد scripts/ وفيه أدوات CLI.
  • اختبارات للتحقق من IR، compiler، backends، وحدود الحزمة.
  • نشر أولي كحزمة npm.
  • إصدار رسمي أولي على GitHub.

هذه ليست مجرد فكرة نظرية؛ إنها حزمة قابلة للتثبيت والتجربة.

لماذا هذا المشروع مهم بالنسبة لي؟

لأنه يجمع أكثر من خط في عملي واهتماماتي.

هناك جانب فني: الأنماط، الزخارف، والهندسة البصرية.

هناك جانب تقني: compiler، schema، API، backends، npm، واختبارات.

هناك جانب معرفي: كيف نمثل الأشياء المعقدة بطريقة تسمح بفهمها وليس فقط استهلاكها.

وهناك جانب مفتوح: تحويل عمل شخصي وبنية بحثية إلى شيء يمكن للآخرين استخدامه.

أنا مهتم بالأنظمة التي تجعل المعرفة قابلة للتصفح، التحليل، والنشر. في هذا المشروع، المعرفة ليست نصًا سياسيًا أو أرشيفًا أو مقالة، بل نمط هندسي. لكن المبدأ نفسه: لا يكفي أن نرى الناتج، يجب أن نفهم البنية.

الخطوة التالية

الخطوات القادمة يمكن أن تسير في أكثر من اتجاه:

  • توسيع أمثلة الأنماط الإسلامية.
  • تحسين دعم interlace والأنماط الشريطية.
  • بناء demo بصري على الويب.
  • تطوير backends جديدة.
  • ربط الأنماط بمصادر ومراجع.
  • بناء طبقة توثيق أعمق.
  • فتح المشروع لمساهمات خارجية.
  • استخدامه كأساس لمعرض أو أطلس بصري للأنماط.

الأهم الآن هو أن تكون الطبقة الأولى واضحة ومستقرة: وصف دلالي، تحقق، تجميع، ومخرجات متعددة.

روابط المشروع

خاتمة

Pattern Geometry Commons هو محاولة صغيرة لكن جدية لنقل الأنماط الهندسية من مستوى الصورة النهائية إلى مستوى البنية القابلة للفهم.

بدل أن تكون الزخرفة ملفًا مغلقًا أو رسمًا ثابتًا، يمكن أن تصبح وصفًا دلاليًا، قابلًا للتحقق، قابلًا للتحويل، وقابلًا للبناء فوقه.

هذا بالضبط ما أريد اختباره: أن يكون لدينا جسر بين الفن والهندسة والبرمجة والأرشفة؛ جسر لا يبدأ من الشكل فقط، بل من المعنى الذي يقف وراء الشكل.

آخر المقالات