Replies: 2 comments 24 replies
-
|
This shouldn't make a difference for us as long as pdfroff is still available. Hopefully the problem with the repository is just temporary. |
Beta Was this translation helpful? Give feedback.
-
|
It's possible, but we'd have to make sure this is fully featured enough. I suspect there were good reasons we went with pdfroff in the first place, but I really don't recall them. |
Beta Was this translation helpful? Give feedback.
-
|
I just tried and the results were pretty good. I needed to specify the fontfamily because the default P wasn't found. I got these errors/warnings: I haven't done a thorough comparison with pdfroff's results, but this is fairly encouraging so far. The warning about Here groff is evidently interpreting I think we can omit |
Beta Was this translation helpful? Give feedback.
-
|
What I've learned so far:
|
Beta Was this translation helpful? Give feedback.
-
|
OK, I've made some improvements in how the works fine with pdfroff but gives you just a string of numbers in the PDF TOC with groff. |
Beta Was this translation helpful? Give feedback.
-
Just got back to my desk... [updated] I've tested with pandoc 3.6.3 (nightly; sliglhtly behind 3.6.4) and found that the full section on Another difference is the file sizes of the PDFs: the [update] The It seems to me that they've just shot their foot. I'll check that anomaly in the Groff development list, to see if this bug/misfeature is already there. |
Beta Was this translation helpful? Give feedback.
-
|
After some research, trial and error, I figured out the following:
in our sample seems to be produced by a faulty conversion of the original So far, this is clear to me. [update] The faulty conversion seems to occur whenever there is some non-alphabetic character in the original string, such as rightparen |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I agree that things like this work But try one with non-ASCII characters: |
Beta Was this translation helpful? Give feedback.
-
|
Overall, it seems to me that the unescaped strings do their job with the gropdf script/engine, acknowledging some limitations. I prepared a test file with pangrams. Indeed, Greek is poorly if supported at all by either script (pdfroff/gropdf): it is faked via the symbol font; and anything beyond Latin 1 is faulty. However, that should be expected, given the limitations of the Base35 Adobe fonts, which are the default on groff. Here is the test.ms file, with UTF8 encoded text, and the result afterwards. And the result from Notice that the Greek Outline/Bookmark produced by pdfroff is rendered correctly by the PDF reader, and not the document itself, because of the limitation of the fonts, and not of the encoding of the string once processed through ghostscript. The outline produced the gropdf script is incorrect because of the limitation of the perl code itself in supporting anything beyond Latin 1 (perhaps Win1252, but I need further testing). Perhaps these limitations deserve a warning in the documentation. |
Beta Was this translation helpful? Give feedback.
-
|
OK, that's good to know that many non-ASCII characters work, and that Greek is a special case. So I think the bottom line is this:
|
Beta Was this translation helpful? Give feedback.
-
|
Created issue #10738. |
Beta Was this translation helpful? Give feedback.
-
|
given the issue open after this general discussion, I think it's about time to move the discussion there... |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
According to an announcement last november, groff has stopped distributing pdfroff as part of the removing of pdfmark; you may find some discussion in this thread. The new repository seems to be broken, at least from my domains. I don't know if this should affect the use/maintenance of the
ms,manor newestmdocformats for generating PDFs.Beta Was this translation helpful? Give feedback.
All reactions