Xử lý tệp Illustrator hoặc pdf thành XAML

Question

Các lựa chọn thay thế để xử lý tệp minh họa hoặc tệp PDF vào XAML là gì. quy trình làm việc hiện tại của tôi làm việc như thế này:

1. Mở tập tin PDF trong Adobe illustrator
2. Lưu tập tin như .ai (Adobe Illustrator) nộp
3. Open in biểu Thiết kế
4. Do một số chế biến, chủ yếu là tách yếu tố để lớp và loại bỏ các phần không cần thiết.
5. Save as XAML
6. Add XAML để Blend dự án

Vấn đề duy nhất của tôi là cách này, văn bản được chuyển đổi sang lối đi. Tôi cũng muốn giữ văn bản của mình trong XAML thay vì đường dẫn.

Có cách nào khác để làm điều này, vì vậy tôi giữ văn bản? Bất kỳ công cụ nào khác?

Answer 1

Có plugin Adobe Illustrator (miễn phí) để xuất sang XAML. Tuy nhiên, bạn không chắc chắn chính xác những gì bạn đang tìm kiếm.

Tìm nó ở http://www.mikeswanson.com/XAMLExport/

Answer 2

Tôi nghĩ rằng những gì bạn muốn là phải có Glyphs yếu tố thay vì Paths. Vấn đề là các phần tử Glyphs yêu cầu bạn chỉ định URI của tệp phông chữ. Ngoài ra, các yếu tố Glyphs tham chiếu đến các chỉ số thành một tệp phông chữ (có thể xảy ra một trình chuyển đổi tạo các phần tử Glyphs - như Microsoft XPS Document Writer - sử dụng các chỉ mục thành các tập con của phông chữ). để cùng một glyphs như được định nghĩa trong tệp phông chữ gốc). Tôi đã có thể "giải quyết" vấn đề này theo hai cách với công cụ chuyển đổi PDF sang XAML của riêng tôi.

1. phương pháp tiếp cận: Nhúng tệp tập hợp con, mã hóa BASE64 vào mã XAML được tạo và yêu cầu ứng dụng triển khai lớp, khi tải, trích xuất và giải mã tệp tập hợp phông được nhúng vào vị trí tạm thời và đưa URI hợp lệ vào tệp tạm thời đó trở lại trình tải XAML.

hoặc, 2. Cách tiếp cận: Có hầu hết các tệp phông chữ đã được cài đặt cùng với ứng dụng của tôi và thêm một số hỗ trợ bằng ứng dụng của tôi thay thế tên phông chữ bằng URI vào tệp phông được cài đặt khi tải XAML mã. Vấn đề với cách tiếp cận thứ hai này là các chỉ mục glyph cần được ánh xạ chính xác đến tệp phông chữ đã cài đặt, có thể không phải là tất cả những điều nhỏ nhặt cần làm. (Bạn có thể tìm thấy liên kết đến một tệp ví dụ đã được tạo cho cách tải này trên blog của tôi: đặc biệt hãy xem qua tệp truncatedcone-xaml.txt)

Tóm lại: cả hai giải pháp đều yêu cầu chuyển đổi PDF sang XAML đặc biệt và hỗ trợ bởi ứng dụng tải. Lý do tôi muốn làm theo cách này thay vì chỉ có các tệp PDF của tôi được chuyển thành Đường dẫn duy nhất là ứng dụng của tôi là bảng trắng được chia sẻ: do đó tôi muốn đồ họa vector của mình là nhỏ nhất có thể. (Chuyển đổi sang các đường dẫn có xu hướng làm nổ tung mã XAML bởi hệ số 10 hoặc nhiều hơn trong hầu hết các trường hợp).

Tôi đang dự tính thực hiện một cách tiếp cận thứ ba : điều này sẽ bao gồm trong việc tạo ra các phác thảo cho mỗi glyph được sử dụng chỉ một lần và sau đó thêm hỗ trợ bởi ứng dụng của tôi để chuyển đổi và vị trí của những hình tượng vạch ra một cách tương tự chặt chẽ với những gì các yếu tố Glyphs làm điều đó nếu không sẽ phải được tạo ra. Lợi thế sẽ là XAML được tạo ra sẽ tương đối nhỏ (so sánh với phương pháp thứ hai được mô tả ở trên) mà không yêu cầu các tệp phông chữ có liên quan được cài đặt cùng với ứng dụng và không cần phải lập chỉ mục các chỉ mục glyph từ một tập con tập tin. Lý do tôi chưa thực hiện điều này một cách nghiêm túc là gấp đôi: thứ nhất, cách tiếp cận hiện tại (thứ hai) của tôi đã hoạt động rất tốt cho những gì tôi hiện đang cần; thứ hai, có thể có các vấn đề về hiệu năng với phương pháp thứ ba này là việc nạp và/hoặc kết xuất các trình thử.

Answer 3

Vâng, tệp XPS thực sự là tệp ZIP. Vì vậy, nếu bạn mở nó với một kho lưu trữ ZIP hoặc nếu bạn đổi tên phần mở rộng của nó thành ZIP, bạn có thể thấy những gì bên trong. Nó đã chứa các trang như mã XAML (các tệp đó có dạng [pagenumber] .fpage). Tuy nhiên, mã XAML đó có thể tham chiếu đến các tệp khác (như hình ảnh raster và tệp tập con phông, đó là các tệp odttf thường - về cơ bản đã mã hóa các tệp kiểu đúng) được bao gồm trong kho lưu trữ ZIP đó. Có nghĩa là, mã XAML mà bạn tìm thấy trong một tài liệu XPS có thể không được sử dụng trực tiếp như XAML thuần túy trong ứng dụng của bạn. Tôi đã viết các kịch bản python để thực hiện việc chuyển đổi XAML lấy từ các tài liệu XPS (được tạo bởi Microsoft XPS Document Writer) để nhận các tệp XAML mà ứng dụng của tôi có thể tải (xem cách tiếp cận 1 và 2 ở trên). Tôi có thể gửi cho bạn các bản sao của các tập lệnh python đó (chúng không phải là mã đặc biệt tuyệt vời, mà không có vấn đề gì đối với tôi vì bây giờ tôi đang sử dụng một cách tiếp cận khác để chuyển đổi PDF sang XAML).

Answer 4

@gyurisc: Giữ các tập tin phông chữ nên làm việc nhưng giữ văn bản có thể bật ra được một vấn đề, bởi vì, bạn sẽ thấy, glyphs không ký tự. Nó có thể là bạn có thể tìm ra nhân vật bằng cách kiểm tra các tập tin phông chữ mà một glyph nhất định là một phần của, nhưng điều đó sẽ liên quan đến phân tích cú pháp các tập tin phông chữ. Nếu bạn không may mắn, trình chuyển đổi PDF sang XPS của bạn thậm chí không giữ đủ thông tin trong các tệp tập hợp con của phông chữ để tìm ra ký tự mà glyph đã cho (rất có thể) đại diện.

Ví dụ: Nếu tôi chuyển đổi tệp PDF sang XPS với sự trợ giúp của XPS Document Writer của Microsoft, sau đó thử chọn một đoạn văn bản từ tài liệu XPS đó, tôi có thể (chỉ rõ ràng) sao chép nó vào khay nhớ tạm. Tuy nhiên, nếu tôi sau đó dán nó trở lại vào một tài liệu Word, tôi nhận được rác. Trong khi đó, nếu tôi chọn cùng một đoạn văn bản trong tài liệu PDF gốc và dán nó vào cùng một tài liệu Word, tôi sẽ nhận được văn bản có ý nghĩa hợp lý. Vì vậy, XPS Document Writer của Microsoft dường như không quan tâm đến việc giải thích một "glyph run" như văn bản, và do đó có vẻ như rất có thể với tôi rằng liên kết giữa các chỉ mục glyph mà người ta tìm thấy trong mã XPS được tạo ra. để đại diện đã bị hỏng tại thời điểm đó. (Nhưng, phải thừa nhận, đó chỉ là phỏng đoán.)

Một đại diện của văn bản (trái ngược với chạy glyph) sẽ là một phần tử TextBlock trong XAML, tôi cho là vậy. Tuy nhiên, tôi đoán là một công cụ chuyển đổi PDF sang XPS điển hình không thể tạo ra các phần tử TextBlock. XPS chủ yếu có nghĩa là được hiển thị - trên màn hình hoặc trên giấy - nó không tự đề xuất như một định dạng tệp đặc biệt thích hợp cho trao đổi dữ liệu (trao đổi văn bản trong trường hợp của bạn).