View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010615 | Scribus | Printing | public | 2012-03-01 13:39 | 2016-05-19 14:52 |
| Reporter | nakamoto | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | All | ||||
| Product Version | 1.4.1.svn | ||||
| Summary | 0010615: Text is treated as graphics in printing, translated PDF is huge. | ||||
| Description | As text is treated as graphics in printing, the same glyph data appears repeatedly in output, makes data huge. Converting the PS output to PDF is almost impractical. --- it is the same in PDF export when OpenType font is used. I investigated the printing code and created a patch to print text as text (it prints to a PDF file only if "pdf" extension is specified, so that it does not break existing functionality ). The detail of the patch is available at: https://sites.google.com/a/borndigital.jp/scribus/scribus-en/printing | ||||
| Steps To Reproduce | Print to a PS file. | ||||
| Additional Information | I attach an archived patch including 2 newly created files. | ||||
| Tags | #pending | ||||
| Patch | |||||
|
|
|
|
|
What for you do compressed patch file? It is breaking Mantis functionality to view patch code online. What do you mean printing? Normal output to printer (not generating PDF)? For me printing to posctscript and then generating PDF from it is impractical - Scribus can generate PDF directly and it is better than printing function. IMHO treating text as graphics is good manner while sending postscript to printer. |
|
|
I have read your explanation on site. And wondering - after your patch is there still possible to send fonts (all or only selected) as outlines to PDF file? |
|
|
I have already attached compressed files in my previous reports. I was not complained at that time. Anyway, I will not attach compressed files in future, but does Mantis allow attaching multiple files ? Scribus PDF output ( export ) is quite useless in my case (OpenType user), as it always converts text using the fonts into graphics ( outline data ) . It does not support font-subsetting, which is really necessary for me. I found Scribus PDF exporter embeds fonts in BeginDoc. So it is impossible to support the functionality without a big rewriting. So, forget about PDF exporter for now. Then I took a look at the printing code ( actually, it never prints on Mac/Linux, just saves a file ? ), as there are many utilities to convert PS to PDF if the output contains text rather than font outline, but Scribus always converts every single glyph into outline. So I investigated Cairo and found that it does font subsetting and output to pdf/ps/svg/png.... With my simple patch, Scribus can save PDF files by specifying ".pdf" extension, and it is the functionality , for those who wants searchable PDF using OpenType fonts. Is my explanation clear enough ? |
|
|
Not clear yet. "Scribus can save PDF files by specifying ".pdf" extension" what exactly means? Step by step if you can explain it for me like for monkey. |
|
|
cezaryce.. whatever can be compressed should be. there's disk space being used you know. Thanks nakamoto for compressing it. |
|
|
"Print to PDF" is the similar to "Print to (PS) File" of Scribus. 1. Build Scribus with my patch applied and launch the program. 2. Create a document, input some text, and choose "print" from menu. 3. If you are working on Windows, specify the target device as "file". 4. Input the output file name which ends with ".pdf" instead of default ".ps" 5. Click "print". |
|
|
For me (r17372 of /branches/Version14x), your patch doesn't apply (although it should as I'm not seeing discrepancies, sorry). I'm also interested in cleaning up your windows-specific code a bit, but I'd like to do that during the day. |
|
|
|
|
|
I have just uploaded 17381-modified.zip, which contains the patched files based on 17381, the latest one as of today. |
|
|
|
|
|
I have just uploaded the patch cleaned up by me (mostly win32-specific part), zipped, including the new files in the patch. I haven't tested the win32 build yet, sorry, I've yet to cross-build it. I don't have OpenType fonts, so couldn't test that, sorry. Is it normal that end-of-line hyphens can't be copied out of a PDF using a subset TrueType font (the alphabetic characters copied fine)? The PDF was created by using your patch (I substantially modified only the win32 part) and printing procedure. |
|
|
I do not think hyphenation is related to font subsetting. Do you mean "SoftHyphen" of Scribus ? Scribus converts text into graphics not only OpenType, but also non-Latin encoded TrueType. For example, STIX math fonts ( http://www.stixfonts.org ) is also drawn as outline by its default PDF generation. In non-Latin region, consequently, almost any text is treated as graphics. |
|
|
Your clean up does not build on Visual Studio 2008. I also noticed that you variant names do not have " " at the top, a font which happens to end with the variant names may be incorrectly truncated. |
|
|
My clean-up contains the space character in the endsWith() test, so that the font variants are listed by their real names, without space. Is that (the usage of the + operator) which doesn't build, or is it my casts from enum to int, or something else? I'll investigate on gcc 4.4 (MinGW cross-building on Linux) first, then I'll see what to do about Visual Studio 2008 (I don't have it). My clean-up also makes listing the "Bold Italic" variant superfluous, because it's a combination of "Bold" and "Italic" which will both be detected. |
|
|
Sorry, I missed space concatenation. VS 2008 express compilation fails at the declaration of "const QStringList fontVariantNames ..." in scpainterex_cairo.cpp. Syntax error. |
|
|
|
|
|
I've just uploaded a version which, at least with gcc 4.4, doesn't give errors about the drawGlyph() method anymore. Sorry that only scpainterex_cairo.cpp is patched by the new zipped patch and the new files aren't in it. I tried to replace the new ZIP file, but got "Access denied" (when deleting) and "duplicate file". |
|
|
It compiles now. |
|
|
It seems Scribus 1.5's scpainterex_cairo now ( r17400) requires cairo 1.12, while the cairo version of macports is 1.10.2. This build cannot be applied on Mac OS X until it is ported. At the time, the pattern below still exists and must be patched for llvm-gcc to compile. - color = transformColor( ScColorShade(stop->color, stop->shade), 1.0 ); + ScColorShade shade = ScColorShade(stop->color, stop->shade); + color = transformColor( shade, 1.0 ); It might be better to redfine the parameter type of transformColor(), as the number of the call has increased. |
|
|
nakamoto can you reproduce this on 1.4.5 (and 1.4.6svn or 1.5.1svn) ? |
|
|
Scribus 1.5 fails in embedding non small fonts - almost any OpenType font. So, it simply exports pdf without font data. But it is not so bad, as it is completely readable and searchable on the same platform. If outlining is specified in pdf export, Scribus converts the text of the outlined fonts into graphics. Untill font subsetting is implemented, this problem persists. The reason I mentioned Cairo pdf a while ago is, that Cairo does font subsetting/embeddnig. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-03-01 13:39 | nakamoto | New Issue | |
| 2012-03-01 13:39 | nakamoto | File Added: patch_for_14x.tar.gz | |
| 2012-03-02 07:54 | cezaryece | Note Added: 0027770 | |
| 2012-03-02 08:01 | cezaryece | Note Added: 0027771 | |
| 2012-03-02 10:56 | nakamoto | Note Added: 0027772 | |
| 2012-03-02 13:49 | cezaryece | Note Added: 0027773 | |
| 2012-03-02 20:47 | cbradney | Note Added: 0027774 | |
| 2012-03-02 23:52 | nakamoto | Note Added: 0027776 | |
| 2012-03-03 00:00 | nakamoto | Note Edited: 0027776 | |
| 2012-03-14 23:19 | jghali | Relationship added | has duplicate 0010630 |
| 2012-03-15 23:28 | mabri | Note Added: 0027823 | |
| 2012-03-15 23:33 | mabri | Note Edited: 0027823 | |
| 2012-03-15 23:33 | mabri | Note Edited: 0027823 | |
| 2012-03-16 01:35 | nakamoto | File Added: 17381-modified.zip | |
| 2012-03-16 01:38 | nakamoto | Note Added: 0027825 | |
| 2012-03-16 16:05 | mabri | File Added: workaround-opentype-win32-cleaned_up.patch.zip | |
| 2012-03-16 16:14 | mabri | Note Added: 0027827 | |
| 2012-03-16 16:15 | mabri | Note Edited: 0027827 | |
| 2012-03-16 16:18 | mabri | Note Edited: 0027827 | |
| 2012-03-16 16:19 | mabri | Note Edited: 0027827 | |
| 2012-03-16 16:20 | mabri | Note Edited: 0027827 | |
| 2012-03-18 01:17 | nakamoto | Note Added: 0027828 | |
| 2012-03-20 03:13 | nakamoto | Note Added: 0027831 | |
| 2012-03-20 16:22 | mabri | Note Added: 0027834 | |
| 2012-03-20 16:22 | mabri | Note Edited: 0027834 | |
| 2012-03-20 22:04 | nakamoto | Note Added: 0027835 | |
| 2012-03-20 23:39 | mabri | File Added: workaround-opentype-win32-cleaned_up-fixed.patch.zip | |
| 2012-03-20 23:47 | mabri | Note Added: 0027836 | |
| 2012-03-20 23:48 | mabri | Note Edited: 0027836 | |
| 2012-03-21 13:37 | nakamoto | Note Added: 0027838 | |
| 2012-03-26 05:55 | nakamoto | Note Added: 0027863 | |
| 2012-04-02 13:07 | nakamoto | Note Edited: 0027863 | |
| 2015-12-05 01:56 | Kunda | Note Added: 0037825 | |
| 2015-12-05 04:31 | nakamoto | Note Added: 0037826 | |
| 2016-05-19 14:52 | Kunda | Tag Attached: #pending |
