سؤال

ما هي البدائل لمعالجة ملفات Illustrator أو ملفات PDF إلى XAML؟يعمل سير العمل الحالي الخاص بي على النحو التالي:

  1. افتح ملف PDF في برنامج أدوبي إليستريتور
  2. احفظ الملف كملف .ai (Adobe Illustrator).
  3. فتح في تصميم التعبير
  4. قم ببعض المعالجة، وبشكل رئيسي فصل العناصر إلى طبقات وإزالة الأجزاء غير الضرورية.
  5. حفظ باسم XAML
  6. أضف XAML إلى مشروع Blend

مشكلتي الوحيدة هي أنه بهذه الطريقة يتم تحويل النص إلى مسارات.أرغب في الاحتفاظ بالنص الخاص بي في XAML أيضًا بدلاً من المسارات.

هل هناك أي طريقة أخرى للقيام بذلك، حتى أحتفظ بالنص؟هل هناك أدوات أخرى؟

هل كانت مفيدة؟

المحلول

هناك مكون إضافي (مجاني) Adobe Illustrator للتصدير إلى XAML. لست متأكدًا من أنه يفعل بالضبط ما تبحث عنه.

تجدها في http://www.mikeswanson.com/xamlexport/

نصائح أخرى

أعتقد أن ما تريده هو الحصول على عناصر الحروف الرسومية بدلاً من المسارات.المشكلة هي أن عناصر الحروف الرسومية تتطلب منك تحديد URI لملف الخط.أيضًا، تشير عناصر الحروف الرسومية إلى الحروف الرسومية حسب فِهرِس في ملف خط (قد يحدث أن المحول الذي يقوم بإنشاء عناصر الحروف الرسومية - مثل Microsoft XPS Document Writer - يستخدم الفهارس في ملفات مجموعة الخطوط الفرعية:لذلك قد لا تكون هذه الفهارس هي الفهارس الصحيحة لنفس الحروف الرسومية كما هو محدد في ملف الخط الأصلي).لقد تمكنت من "حل" هذه المشكلة بطريقتين باستخدام أدوات تحويل PDF إلى XAML الخاصة بي.

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

أو، 2.يقترب:تثبيت معظم ملفات الخطوط بالفعل مع تطبيقي، ومرة ​​أخرى، إضافة بعض الدعم من خلال تطبيقي الذي يستبدل اسم الخط بمعرف URI إلى ملف الخط المثبت عند تحميل كود XAML.المشكلة في هذا الأسلوب الثاني هي أن فهارس الحروف الرسومية تحتاج إلى أن يتم تعيينها بشكل صحيح إلى ملف الخط المثبت، وهو ما قد لا يكون أمرًا تافهًا.(يمكنك العثور على رابط لملف نموذجي تم إنشاؤه لهذه الطريقة للتحميل على مدونتي:على وجه الخصوص، قم بإلقاء نظرة خاطفة على الملف truntedcone-xaml.txt)

باختصار:يتطلب كلا الحلين محولاً خاصًا من PDF إلى XAML ودعمًا من تطبيق التحميل.السبب وراء رغبتي في القيام بذلك بهذه الطريقة بدلاً من تحويل ملفات PDF الخاصة بي إلى مسارات فقط هو أن تطبيقي عبارة عن لوحة معلومات مشتركة:وبالتالي أريد أن تكون الرسومات المتجهة الخاصة بي كما هي صغيرة قدر الإمكان.(يميل التحويل إلى المسارات إلى تفجير كود XAML بعامل 10 أو أكثر في معظم الحالات).

أفكر في تنفيذ أ النهج الثالث:سيتكون هذا من إنشاء المخطط التفصيلي لكل حرف رسومي يتم استخدامه مرة واحدة فقط ثم قم بإضافة الدعم من خلال تطبيقي لتحويل هذه الخطوط العريضة للصور الرمزية ووضعها بطريقة تشبه إلى حد كبير ما تفعله عناصر الحروف الرسومية والتي كان من الممكن إنشاؤها بطريقة أخرى.تتمثل الميزة في أن XAML الذي تم إنشاؤه سيظل صغيرًا نسبيًا (مقارنة بالطريقة الثانية الموضحة أعلاه) دون الحاجة إلى تثبيت ملفات الخطوط ذات الصلة مع التطبيق ودون الحاجة إلى تعيين فهارس الحروف الرسومية من ملف مجموعة فرعية إلى الخط المثبت ملف.السبب وراء عدم محاولتي تنفيذ ذلك بشكل جدي هو ذو شقين:أولاً، يعمل أسلوبي الحالي (الثاني) بشكل جيد جدًا فيما أحتاج إليه حاليًا؛ثانيًا، قد تكون هناك مشكلات في الأداء مع هذا النهج الثالث فيما يتعلق بالتحميل و/أو العرض.

حسنًا ، ملف XPS هو في الواقع ملف مضغوط. لذا ، إذا فتحته باستخدام Archiver Zip أو إذا قمت بإعادة تسمية امتداده إلى Zip ، فيمكنك رؤية ما بداخله. إنه يحتوي بالفعل على الصفحات كرمز XAML (تحتوي هذه الملفات على النموذج [Pagenumber] .FPAGE). ومع ذلك ، قد يشير رمز XAML إلى ملفات أخرى (مثل الصور النقطية وملفات مجموعة الخطوط الفرعية ، عادة ما تكون ملفات ODTTF - ملفات النوع الحقيقي المشفر بشكل أساسي) والتي يتم تضمينها في أرشيف الرمز البريدي أيضًا. مما يعني أن رمز XAML الذي تجده في مستند XPS قد لا يكون قابلاً للاستخدام مباشرة كـ XAML PURE في التطبيق الخاص بك. لقد كتبت البرامج النصية Python للقيام بتحويل XAML مأخوذة من مستندات XPS (التي تم إنشاؤها بواسطة Microsoft XPS Document) للحصول على ملفات XAML التي يمكن أن يتم تحميلها (انظر الأساليب 1 و 2 أعلاه). يمكنني أن أرسل لك نسخًا من برامج النصوص التي يتمتع بها بيثون (فهي ليست رمزًا رائعًا بشكل خاص ، وهو ما لا يمثل مشكلة بالنسبة لي لأنني الآن أستخدم نهجًا مختلفًا لتحويل PDFs إلى XAML على أي حال).

GyUrisc: يجب أن يعمل الاحتفاظ بملف الخط ولكن الاحتفاظ بـ نص قد تتحول إلى مشكلة ، لأنك ترى ، الحروف الرسومية ليست شخصيات. قد يكون يمكنك معرفة الحرف من خلال فحص ملف الخط الذي يعتبره حرفي معين جزءًا منه ، لكن ذلك سيتضمن تحليل ملف الخط. إذا كنت محظوظًا ، فإن محول PDF إلى XPS الخاص بك لا يحتفظ حتى بالمعلومات الكافية في ملفات المجموعة الفرعية لمعرفة الحرف الذي يمثله Glyph (من المحتمل جدًا).

على سبيل المثال: إذا قمت بتحويل ملف PDF إلى XPS بمساعدة كاتب مستندات XPS من Microsoft ، ثم حاول تحديد قطعة من النص من مستند XPS ، يمكنني (على ما يبدو فقط) نسخه إلى الحافظة. ومع ذلك ، إذا قمت بصقها مرة أخرى في مستند Word ، أحصل على القمامة. بينما إذا اخترت ذلك نفس قطعة من النص في مستند PDF الأصلي ولصقها في نفس مستند Word ، أحصل على نص ذي معنى معقول. لذلك يبدو أن كاتب مستندات XPS من Microsoft لا يهتم بتفسير "تشغيل الرسول الرسمية" كنص ، وبالتالي يبدو أنه من المحتمل جدًا أن يكون الصلة بين مؤشرات الرسول الرسمية التي يجدها المرء في رمز XPS الذي تم إنشاؤه والأحرف التي تعنيها تمثل تمثيل بالفعل في تلك المرحلة. (ولكن ، من المسلم به ، هذا مجرد تخمين.)

تمثيل نص (على عكس مجموعة من الحروف الرسومية) سيكون عنصر نص في XAML ، أفترض. ومع ذلك ، أعتقد أن محول PDF إلى XPS نموذجي من غير المرجح أن ينشئ عناصر نصية. يُقصد من XPS أن يتم تقديمه بشكل أساسي - على الشاشة أو على الورق - لا يقترح نفسه كتنسيق ملف مناسب بشكل خاص لتبادل البيانات (تبادل النص في حالتك).

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top