Bu cevap tüm testlerden geçer , ancak akış çizelgesi test belgenizde bir tanedir.
sudo apt-get install unoconv
doc2pdf respondus-docx-sample-file.docx
Bu neden bugüne kadar önerilenden daha iyi?
Şu ana kadar önerilen diğer yöntemleri (özellikle oowriterve ebook-convert) test ettim , ancak bu yöntemden daha az test geçirdiler. ebook-convertYöntem marjlarını ve belgenin dışarı metinlerinin bir parçasını söker.
Bu yöntem bile rainbowpdf olarak profesyonel bir dönüştürücüden daha iyi sonuçlar verir .
Ayrıca onu html'ye çevirmeyi de denedim, ancak dairenin karesi ve akış şemasındaki çizim yanlış.
Akış şeması testi neden başarısız?
Görünüşe göre libreoffice ve unoconv, .docx dosyasındaki akış şemasını doğru şekilde göstermekte bazı problemler yaşamaktadır. Bu muhtemelen Microsoft Office'te akıllı sanat kullanılarak yapıldığı içindir . Sorun bu. Bu da bu konu üzerinde tartışılan bir hatadır . Metinsel ve görsel bilgi, pdf'te yukarıdaki yöntemden görebileceğiniz gibi bulunmaktadır (yine de metni seçmek zorunda kaldım).
Örneğin, yazı tipi rengi düzgün okunmuyor ve bazı satırlar çok uzun. Akıllı sanatı doğru gösterebilecek herhangi bir linux çözümünün farkında değilim. :(
Bu, printbu sayfada yayınlanan tüm çözümlerin sizi tatmin etmemesinin nedeni de budur .
Kısacası
Kısacası, yaptığınız şey gerçekten zor ve şu anda sizi tamamen tatmin edecek hiçbir çözüm yok. Docx2pdf dönüşümlerinin aşil topuğu akıllı sanattır. O olmadan yaşayabilir veya akıllı sanatı tespit etmenin ve bir şekilde bir görüntüye dönüştürmenin bir yolunu bulursanız , hedefinize ulaşabilirsiniz.
Seçenek 1. Kullanıcılarınızı sorunla baş etmeye zorlayın
Bu çok tuhaf bir çözüm. İçerik oluşturucularınız akıllı sanatlarını ofis yardım sayfalarında açıklandığı şekilde jpg olarak kaydedebilir ve bu nedenle sunucunuzda dönüşüm mümkün olabilir.
Seçenek 2. Problemi çözerken yolunuzu kırın
Akış şemaları genellikle çok benzerse ve ne kadar iyi bir geliştirici olduğunuza bağlı olarak, akıllı sanatı ayrı ayrı deneyebilir ve dönüştürebilirsiniz. Drawing1.xml dosyasını .docx belge kümesinden çıkarın ve akıllı bir sanatı yeniden oluşturmak için doğal dil işlemeyi ve bazı çılgın kesimleri kullanın. Örneğin, bu tür xml'lerle uğraşmanız gerekir:
<dsp:txBody>
<a:bodyPr spcFirstLastPara="0" vert="horz" wrap="square" lIns="8255" tIns="8255" rIns="8255" bIns="8255" numCol="1" spcCol="1270" anchor="ctr" anchorCtr="0">
<a:noAutofit/>
</a:bodyPr>
<a:lstStyle/>
<a:p>
<a:pPr lvl="0" algn="ctr" defTabSz="577850">
<a:lnSpc><a:spcPct val="90000"/>
</a:lnSpc>
<a:spcBef>
<a:spcPct val="0"/>
</a:spcBef>
<a:spcAft>
<a:spcPct val="35000"/>
</a:spcAft>
</a:pPr>
<a:r>
<a:rPr lang="en-US" sz="1300" b="1" kern="1200"/>
<a:t>All three sides are different lengths
</a:t>
</a:r>
</a:p>
</dsp:txBody>
Veya asgari bir çözüm olarak, en azından metni ( ?) Dosyadan ayıklayın ve <a:t>daha kolay bir şekilde kaydedin. Veya pdfs dosyanızın akış çizelgeleri aynıysa, xml'nin içindeki metin rengini ve satır uzunluğunu değiştirmek için bir komut dosyası yazabilirsiniz. Sonra koşabilir doc2pdfve temelde tüm doğru bilgileri içeren bir dosyaya sahip olabilirsiniz , ama belki de biçimlendirmeyi değil. Akış çizelgeleri söz konusu olduğunda, muhtemelen biçimlendirmenin bir kısmı olduğundan, biçimlendirmenin bir kısmını da dahil etmek istersiniz .
Seçenek 3. Üçüncü taraf bir servisi kullanın
Son birkaç gündür biraz daha araştırma yaptım ve dönüşümü mükemmel yapan bir servis buldum: zamzar . Zamzar, bir docx dosyası yüklemenize izin verir ve ardından size bir e-posta gönderir. Ayrıca, pdf@zamzar.com adresine herhangi bir dosyayı gönderebileceğiniz ve dönüştürülen dosyayı gelen kutunuza geri alabileceğiniz (ücretli?) Bir hizmeti vardır. Bu dosyayı kolayca otomatik olarak gönderdiğiniz ve e-postadan ayrıştırdığınız bir sistem oluşturabilirsiniz. Bu çok fazla iş değil ve sonuç en iyisidir.
notlar
- Herhangi birinin aynı şeyi yapan başka hizmetleri varsa, lütfen bunları düzenlemek için çekinmeyin.
- Bir api olup olmadığını sormak için zamzar desteğini gönderdim. Bu daha kolay olurdu.
- Belki apose .NET ve Java için de yardım edebilir? Veya bu çok ilişkili SO yazısında olduğu gibi docx4java .
- Başka bir seçenek de, tarihli ve kütüphanecilikten ziyade openoffice'e bağlı olan odf dönüştürücüye bakmaktır .
- Java jodconverter'ın da sıkıntı yaşadığını doğrulayabilirim , akış şeması dönüşümünde başarısız olur.
Bu sayfada önerilen farklı yöntemleri denemek için zaman ayırdım. Lütfen gerçek testlerle ilgili yorumlarınızı geri alın.
