English version

أطلقت مؤخرًا مشروعًا مفتوح المصدر باسم 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/>توجيه عملية التحويل"]
  registry["Backend Registry<br/>اختيار محوّل الإخراج"]
  svg["SVG"]
  makerJson["Maker.js JSON"]
  makerSvg["Maker.js SVG"]
  dxf["DXF"]
  custom["Custom Backend<br/>registerBackend"]

  ir --> validator --> compiler --> registry
  registry --> svg
  registry --> makerJson
  registry --> makerSvg
  registry --> dxf
  custom -. "تسجيل" .-> registry

الـ 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 محاولة صغيرة وجادة لنقل الأنماط الهندسية من مستوى الصورة النهائية إلى مستوى البنية القابلة للفهم.

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

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