Not logged in. · Lost password · Register
Forum: General Help and Support Features and Functionality RSS
Dokuwiki as a DMS
Page:  1  2  next 
Avatar
pernils #1
Member since Feb 2012 · 21 posts
Group memberships: Members
Show profile · Link to this post
Subject: Dokuwiki as a DMS
Hi .

My name is Pernils and I been struggling to make DW as a backbone for DMS.

The basic idea was:

Samba share for make a folder inside the ..dokuwiki/data/media/ accesible outside the DW enviroment.
The inserted pdf files to that folder would then go throu the process: pdftohtml -> html2wiki.

The resault (...txt file) would then be inserted into DW to make the doucment searchable.

I have used all my spare time for over 2 months on this project just to discovered that the output from html2wiki will not be usable. Html2wiki will produce just garbage.

After researche I found that there is a php lib http://simplehtmldom.sourceforge.net/ that could be used to write a php html parser.
Due the fact I have wasted so many hour on this and I have only written some simple hello world in php I have decided to stop here.

So my question is:

Does someone have a another html2wiki parser?

Some attempts have been done by Andreas Gohr  http://www.freelists.org/post/dokuwiki/dokuwiki2html. (would be intressted to know how it worked).

My wiki thread on this project could be read on http://www.dokuwiki.org/sv:samba_pdf_to_wiki (sorry only in swedish)

If someone is intressted maybe Håkan Sandel (du verkar vara aktiv i DW) could extract the most imported parts and translate to English. Personaly I have lost all my energy after been defeted by the garabe output from html2wiki.
Avatar
HansBKK #2
Member since Nov 2011 · 104 posts · Location: Bangkok
Group memberships: Members
Show profile · Link to this post
Why have you got stuff in PDF to start with? That's a lousy "master source" format for content intended to be converted to other formats. PDF should be a "final output" format generated from a plaintext "light markup" syntax, usually after tweaking in LaTeX.

I also consider HTML an output format, rarely does conversion *from* HTML work well for anything other than headers and simple inline formatting like bold/italic etc.

I suggest taking a look at the txt2tags and pandoc projects - the latter is much more actively developed these days, with good support in their googlegroups mail list. reST/Sphinx is also a good mature environment, but much more limited publishing output choices, HTML and PDF only I believe, check out a reasonably complete matrix here:
https://docs.google.com/spreadsheet/…?key=0Ali3YyiUxdiAd…

You may not want to use DW's markup syntax unless you create reader/writer modules for pandoc to automate conversion to more standard formats, but it will work fine as a "transparent carrier" to allow for collaborative editing.

You may also want to look at the various wiki platforms that run on top of distributed VCS if you've got a small group, don't need general access via the Internet. Gitit is maintained by the author of pandocs so uses its extended markdown syntax, obviously rides on Git.

Hope this helps.
Avatar
ach (Administrator) #3
Member since May 2006 · 1914 posts · Location: Folkestone, UK
Group memberships: Administrators, Members, Super Mods, Wiki Managers
Show profile · Link to this post
In reply to post #1
Quote by pernils:
The basic idea was:

Samba share for make a folder inside the ..dokuwiki/data/media/ accesible outside the DW enviroment.
The inserted pdf files to that folder would then go throu the process: pdftohtml -> html2wiki.

The resault (...txt file) would then be inserted into DW to make the doucment searchable.

Why exactly did you try to do that? I can think of two scenarios:
a) You (or your company or a client) have a lot of PDFs and want to get them into a wiki (with its advantages: searchable, etc).
b) You'd like to do this as a general exercise (e.g. for uni) and think that others would need something like that as well.

In the case of a), it might be better and cheaper and quicker to hire someone to manually add all the information from the PDFs into the wiki. This, obviously, depends on the amount of PDFs that needs to be converted. But at least the quality will be much better.

Or is there any other reason why you'd like to do that?
Avatar
pernils #4
Member since Feb 2012 · 21 posts
Group memberships: Members
Show profile · Link to this post
In reply to post #2
The reason that I have chosen pdf is that is available from many program in my working environment (writer, solid edge, word ..)

When I wrote that I would use DW as a DMS i meant it would just act a indexer of the content of the inserted docs (drawings doc etc ..). Each new created wiki page would have a link to it's original pdf file if you want to print mail or whatever....

Did it make sense? hmm I don't think so. I will try explain again.

I am searching for lightweight platform for adding data . could be ..customer list, phone book, field service, meetings, manuals, problem solving ... you name it.
The main feature would to search through all this content.

When i comes to complex manuals with pictures it's much easier to use a local tool like writer for example. Therefore some import function is needed. PDF seems to be the best choice for the carrier.


I have tried Alfresco but due it's written in java it rely sucks power from the hardware.. anyway the left over box i tested soon stopped responding and continue to spin the harddrive to I turn of the power. I didn't fully evaluate it possibilities but I don't think it could import pdf or indexing the uploaded documents.

Have tried some other tools also but I don't like when they don't preserve the filenames.

Then I discovered DW and then link http://www.dokuwiki.org/tips:doc_to_wiki_syn…?&#doku… . Fine this could relay be something. The after all research compiling pdftohtml html2wiki and bash scripting. I had a automatic working solution but with the drawback ... result was garbage. Probably 200 man hour down the drain ...

I have dropped some html snippet from the pdftohmtl output http://www.dokuwiki.org/playground:html if someone thinks "this look interesting".

It must be more people out there then just me looking for the same solution.

But thanks HansBKK for pointing to the pandoc tool.
Avatar
pernils #5
Member since Feb 2012 · 21 posts
Group memberships: Members
Show profile · Link to this post
ACH ...

It's the scenario a)

Today we have not any tool for collaborate all the documents .. they are scattered all over the network. I know that DW maybe is not the best tool for this .. but could be step on the way for merging all that data into one place and to make it easier for others to find what they are searching for.
Avatar
ach (Administrator) #6
Member since May 2006 · 1914 posts · Location: Folkestone, UK
Group memberships: Administrators, Members, Super Mods, Wiki Managers
Show profile · Link to this post
Quote by HansBKK:
Why have you got stuff in PDF to start with? That's a lousy "master source" format for content intended to be converted to other formats. PDF should be a "final output" format generated from a plaintext "light markup" syntax, usually after tweaking in LaTeX.

I fully agree with that.

Quote by pernils:
When I wrote that I would use DW as a DMS i meant it would just act a indexer of the content of the inserted docs (drawings doc etc ..). Each new created wiki page would have a link to it's original pdf file if you want to print mail or whatever....

I think that's a bad idea. You'll nearly completely lose the power of a wiki with that solution. I still don't understand why PDF needs to be the input format. I would rather use the wiki normally with its wiki syntax. And if you need a PDF later on, you can always simply export it (with either the dw2pdf or the odt plugin).

Quote by pernils:
I am searching for lightweight platform for adding data . could be ..customer list, phone book, field service, meetings, manuals, problem solving ... you name it.
The main feature would to search through all this content.

Sounds like a perfect job for a wiki to me (and not a bunch of PDFs). ;-)

Quote by pernils:
When i comes to complex manuals with pictures it's much easier to use a local tool like writer for example. Therefore some import function is needed. PDF seems to be the best choice for the carrier.

I very much disagree with that. Using only local tools is what usually gets you into that mess you are now in. ;-)
Why do you think writer is an easier tool than DokuWiki? There are very few things that cannot be done with DokuWiki. And it's usually easier to mess things up and lose focus with a tool like writer.

And PDF is not a good choice at all for a carrier, except as a carrier to the printer.

Quote by pernils:
ACH ...

It's the scenario a)

Today we have not any tool for collaborate all the documents .. they are scattered all over the network. I know that DW maybe is not the best tool for this .. but could be step on the way for merging all that data into one place and to make it easier for others to find what they are searching for.

I'd say DokuWiki is a perfect tool for that! You know what? That's exactly the same scenario (that will be all too familiar to a lot of people) that got DokuWiki started in the first place! Back in 2004 our company was fed up with all the mess and different documents on the fileserver and Andreas Gohr was given the task to install a wiki to improve our intranet. But because he couldn't find one which he liked, he just created his own. The rest is, as they say, history...

But DokuWiki is not the only tool for that. Some other wiki engines or txt2tags and pandoc (as HansBKK pointed out) could serve the same purpose with equally good results.
Avatar
HansBKK #7
Member since Nov 2011 · 104 posts · Location: Bangkok
Group memberships: Members
Show profile · Link to this post
In reply to post #4
Thanks for clarifying your use case, much easier to give advice more concisely.

If you aren't already saddled with a bunch of pre-existing content, avoid PDF except as a way to "publish final" pretty-printed output. Don't focus on the authoring software, focus on the choice of "master source" syntax, and select/adapt your tools to suit that. Once you've got a lot of content, you're kind of "locked in" to the capabilities of the related tools unless you're willing to sponsor new software.

IMO Generic plain text is the best carrier format, with one of the "light markup" syntaxes to handle formatting.

The only problem with DW is that it's web-based UI is based on its "proprietary" syntax. However if that's going to be the "master content" home/carrier, then it shouldn't be too hard to convert from that syntax to say Pandoc for further publishing. I think I pointed out elsewhere that the author of Zim has created a python script that converts from zim-wiki syntax (very very close to DW) to pandoc.

Once that's in place, then DW can be the authoring/editing environment in many cases, but those that prefer other text processing tools can still use those directly.

If pandoc becomes important to your workflow, then a major contribution to the DW project would IMO be a plugin that allowed it to support Pandoc directly, both in the editor UI and in the rendering engine.

And learn from your experience - get to know the individual tools properly before assuming they will become part of your toolchain. There's no such thing as "wiki text" other than a general concept (which I refer to as "lightly marked up plain text"), there are hundreds of syntax flavors and for non-programmers converting accurately between these is not a trivial problem domain.
Avatar
pernils #8
Member since Feb 2012 · 21 posts
Group memberships: Members
Show profile · Link to this post
In reply to post #6
Quote by ach:
Quote by HansBKK:
Why have you got stuff in PDF to start with? That's a lousy "master source" format for content intended to be converted to other formats. PDF should be a "final output" format generated from a plain text "light markup" syntax, usually after tweaking in LaTeX.

I fully agree with that.
When writing stuff to explain some function for product or service instruction you want to include so many pictures as possible. The pictures that we/I use is mostly generated from our 3D cad software.
When I use writer I would then have a break in the update chain. If I make a adjustment to 3d model i must redo the picture and paste back into writer.
So for document that would include many illustration I have used the draft environment in Solid Edge. Then I can edit the 3d models how much I want .. and open the draft file and press "update links" and all pictures that is generated from 3D models will be updated.
2D export possibilities from Solid Edge is .pdf, .dxf, .dwg and is native format .dft.

As you can see the best choice in this case is pdf.

When we come to word processors .. we have 2 groups. 1 group that is flexible (like me) that could use what ever word processor but have been chosen Libre Office. The other group is to lazy to relearn another GUI (using word). In my opinion wordpad would be more than enough for how they use to write. They don't use format etc .. you know how it works.

As you can see the best generic carier to get this content into DW is pdf. I'm not so interested to get the for example a manual back from DW into pdf for mailing. Then it's better to get the orginal pdf.
DW will help me to find the right manual due to it search function. The page with the most hits must best explain the keywords.

Quote by ach:
Quote by pernils:
When I wrote that I would use DW as a DMS i meant it would just act a indexer of the content of the inserted docs (drawings doc etc ..). Each new created wiki page would have a link to it's original pdf file if you want to print mail or whatever....

I think that's a bad idea. You'll nearly completely lose the power of a wiki with that solution. I still don't understand why PDF needs to be the input format. I would rather use the wiki normally with its wiki syntax. And if you need a PDF later on, you can always simply export it (with either the dw2pdf or the odt plugin).

It's a dunting task to make document/page in DW that contains a lot of pictures. You have the upload procedure and you don't see the result before you press preview. Okey you have some WYSIWYG editor possibility in DW but will not be as fast as with a local tool.


Quote by ach:
Quote by pernils:
I am searching for lightweight platform for adding data . could be ..customer list, phone book, field service, meetings, manuals, problem solving ... you name it.
The main feature would to search through all this content.

Sounds like a perfect job for a wiki to me (and not a bunch of PDFs). ;-)
I agree .. but not when it comes to embedded pictures.

So my struggling is to use DW as indexer for documents made from different tools (write, word soldiegde etc ..) but whit the bonus that it have the wiki possibilities.

hmm.. My native language is Swedish not English .. i think when I in the future look back on this I want understand my self either.
Avatar
pernils #9
Member since Feb 2012 · 21 posts
Group memberships: Members
Show profile · Link to this post
I have include the html output from pdftohtml and erased it from the playground. Just to keep this thread self contained.
  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  2. <TITLE>��</TITLE>
  3. <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
  4. <META name="generator" content="pdftohtml 0.39">
  5. <META name="author" content="��">
  6. <META name="keywords" content="��">
  7. <META name="date" content="2009-02-27T13:17:53+00:00">
  8. <META name="subject" content="��">
  9. </HEAD>
  10. <BODY bgcolor="#A0A0A0" vlink="blue" link="blue">
  11. <!-- Page 1 -->
  12. <a name="1"></a>
  13. <DIV style="position:relative;width:892;height:1263;">
  14. <STYLE type="text/css">
  15. <!--
  16.     .ft0{font-size:9px;font-family:Helvetica;color:#000000;}
  17.     .ft1{font-size:27px;font-family:Helvetica;color:#000000;}
  18.     .ft2{font-size:18px;font-family:Helvetica;color:#000000;}
  19.     .ft3{font-size:9px;line-height:13px;font-family:Helvetica;color:#000000;}
  20.     .ft4{font-size:18px;line-height:23px;font-family:Helvetica;color:#000000;}
  21. -->
  22.  
  23. </STYLE>
  24. <IMG width="892" height="1263" src="ventilpatroner001.png" alt="background image">
  25. <DIV style="position:absolute;top:56;left:806"><span class="ft0">1 (2)</span></DIV>
  26. <DIV style="position:absolute;top:82;left:725"><span class="ft0">2009-02-26 - 62902</span></DIV>
  27. <DIV style="position:absolute;top:1165;left:547"><span class="ft3">SMP Parts AB, Bergsjövägen 3 82071 ILSBO Sweden<br>Tel + 46 (0)650 35650, Fax + 46 (0)650 35660<br>E-mail: info@smpparts.com</span></nobr></DIV>
  28. <DIV style="position:absolute;top:82;left:69"><span class="ft1">VENTILPATRONER</span></DIV>
  29. <DIV style="position:absolute;top:177;left:68"><span class="ft2">Ventilpatrons programmet kommer i huvudsak ifrån Integrated Hydraulics.</span></DIV>
  30. <DIV style="position:absolute;top:224;left:68"><span class="ft2">Allmänt om ventiler och deras benämning samt dess funktion.</span></DIV>
  31. <DIV style="position:absolute;top:271;left:68"><nobr><span class="ft4">Riktningsventil -&gt; ventiler som bestämmer riktning på oljan eller till vilka portar<br>som oljan skall ansättas.</span></nobr></DIV>
  32.  
  33. <DIV style="position:absolute;top:340;left:68"><nobr><span class="ft2">Tryckreducerare -&gt; Avgränsar det inställda trycket genom att dränera till tank.</span></nobr></DIV>
  34. <DIV style="position:absolute;top:387;left:68"><nobr><span class="ft4">Tryckbegränsare -&gt; Avgränsar det inställda trycket genom att bara släppa<br>igenom olja tills trycket har uppnåts.</span></nobr></DIV>
  35. <DIV style="position:absolute;top:457;left:68"><nobr><span class="ft4">Chockventil -&gt; Kontrollera trycket i en port för att släppa över övertrycket till<br>annan port.</span></nobr></DIV>
  36. <DIV style="position:absolute;top:527;left:68"><nobr><span class="ft2">Back ventil -&gt; Säkerställa att oljan bara går åt ett håll.</span></nobr></DIV>
  37.  
  38. <DIV style="position:absolute;top:573;left:68"><nobr><span class="ft4">Pilot styrd backventil -&gt; Säkerställa att trycket inte kan återgå förrän ett pilot tryck<br>öppnar käglan och gör det möjligt.</span></nobr></DIV>
  39. <DIV style="position:absolute;top:643;left:68"><nobr><span class="ft4">Overcenter -&gt; Har samma funktion som pilot styrd backventil men den funtion att<br>om trycket skulle överstiga det instälda så kommer &quot;back ventilen&quot; att öppna sig<br>ändå.</span></nobr></DIV>
  40. </DIV>
  41. <!-- Page 2 -->
  42. <a name="2"></a>
  43.  
  44. <DIV style="position:relative;width:892;height:1263;">
  45. <STYLE type="text/css">
  46. <!--
  47.     .ft5{font-size:15px;font-family:Helvetica;color:#007f7f;}
  48.     .ft6{font-size:15px;line-height:19px;font-family:Helvetica;color:#007f7f;}
  49. -->
  50. </STYLE>
  51. <IMG width="892" height="1263" src="ventilpatroner002.png" alt="background image">
  52. <DIV style="position:absolute;top:56;left:806"><nobr><span class="ft0">2 (2)</span></nobr></DIV>
  53. <DIV style="position:absolute;top:82;left:725"><nobr><span class="ft0">2009-02-26 - 62902</span></nobr></DIV>
  54. <DIV style="position:absolute;top:1165;left:547"><nobr><span class="ft3">company adress etc ...<br>Tel + ******<br>E-mail: info@company.com</span></nobr></DIV>
  55. <DIV style="position:absolute;top:82;left:69"><nobr><span class="ft1">VENTILPATRONER</span></nobr></DIV>
  56. <DIV style="position:absolute;top:207;left:268"><nobr><span class="ft6">65990<br>VENTIL PATRON 1PA100</span></nobr></DIV>
  57.  
  58. <DIV style="position:absolute;top:382;left:261"><nobr><span class="ft6"> 60222<br>VENTIL PATRON 1PA60</span></nobr></DIV>
  59. <DIV style="position:absolute;top:514;left:266"><nobr><span class="ft6">62948<br>VENTIL PATRON 1CLLR100 (@210BAR)</span></nobr></DIV>
  60. <DIV style="position:absolute;top:694;left:263"><nobr><span class="ft6">62902<br>VENTIL PATRON 1AR60-P-35S SET@210BA</span></nobr></DIV>
  61. <DIV style="position:absolute;top:829;left:263"><nobr><span class="ft6">63374<br>VENTIL PATRON 1CER30 (@210 BAR)</span></nobr></DIV>
  62. <DIV style="position:absolute;top:979;left:262"><nobr><span class="ft6">636121<br>VENTIL 4CK30-3s</span></nobr></DIV>
  63. </DIV>
  64.  
  65. </BODY>
  66. </HTML>
Does this forum have syntax highlighting ?
This post was edited 2 times, last on 2012-02-24, 14:55 by ach.
Avatar
pernils #10
Member since Feb 2012 · 21 posts
Group memberships: Members
Show profile · Link to this post
Just to give some example of pdf file.

http://www.eaton.com/ecm/groups/public/@pub/@eaton/@hyd/do…

This is much more complex than I will produce but to manually export this into DW will take a lot of effort. I tested to run this throw the pdftohtml tool and it looked fair enough. But when i moved on with html2wiki it will be just rubbish.

Maybe some php string chopping enthusiast find this as a fun task and will contribute to extend the DW possibilities. My self with just some php skills find this task going over my head.

But it would be good exercise for learning string chopping in php ... maybe in the future ...
Avatar
HansBKK #11
Member since Nov 2011 · 104 posts · Location: Bangkok
Group memberships: Members
Show profile · Link to this post
I'm not trying to sell you on using DokuWiki as everyone's editor, but I would still recommend standardizing an optimal workflow if at all possible, and IMO at least the text portion should be kept as "master source" in plaintext.

You could then output to two separate "next stages":
  A. generate say HTML or RTF, whatever the "word processors" the users are working for the pretty-print formatting can accept.
  B. DokuWiki - I'm still not clear what the need is there, just indexing key-word lookups?

If you decide on a way to include/reference the graphic files in the master source, and can allow the later-revised graphic files to have the same name as they had before, no updates are needed for the links, just upload the new files.

Or look for software that's intended to be a DMS and indexes the text within the PDFs for you.
Avatar
ach (Administrator) #12
Member since May 2006 · 1914 posts · Location: Folkestone, UK
Group memberships: Administrators, Members, Super Mods, Wiki Managers
Show profile · Link to this post
In reply to post #10
Quote by pernils:
This is much more complex than I will produce but to manually export this into DW will take a lot of effort. I tested to run this throw the pdftohtml tool and it looked fair enough. But when i moved on with html2wiki it will be just rubbish.

Looking at the example code above, I have to say that you are wrong. It's pdftohtml which is bad and not html2wiki! Because the output html is so bad, no wonder that html2wiki cannot do anything with it. Although, it might not be pdftohtml's fault, but the original PDF could already be bad. (PDF != PDF)
Avatar
ach (Administrator) #13
Member since May 2006 · 1914 posts · Location: Folkestone, UK
Group memberships: Administrators, Members, Super Mods, Wiki Managers
Show profile · Link to this post
In reply to post #9
Quote by pernils:
Does this forum have syntax highlighting ?

I edited your post to include syntax highlighting ([ code=html ]).
Avatar
pernils #14
Member since Feb 2012 · 21 posts
Group memberships: Members
Show profile · Link to this post
Quote by HansBKK:
If you decide on a way to include/reference the graphic files in the master source, and can allow the later-revised graphic files to have the same name as they had before, no updates are needed for the links, just upload the new files.
If I take the example to write a document for all the different valves have been using in our products. The most flexible tool is to do it right in the Solid Edge 3D software. If some one make adjustment to a part (valve) make it look better I just have to open the draft and press update and the illustration will update it self.

If I use a "static" picture like working in word .. I have to:
fire up the 3D software
make a new draft
insert the part (valve/ engine or whatever) with the right postition
save as jpg (gives better resolution) or mark -> copy
paste it in word and sometimes use the crop function inside writer/word.

The more step it takes the liker it wouldn't be done.

I will mail you a link to my working environment ...

Hmm access denied  .. I don't want to publish the url in the public.
This post was edited 3 times, last on 2012-02-24, 22:22 by pernils.
Avatar
pernils #15
Member since Feb 2012 · 21 posts
Group memberships: Members
Show profile · Link to this post
So to getting back to topic .. more how and less why ...

pdftohtml is producing the same html output from all the different "pdf making sources" I have tried.

It's build on xpdf.. maybe gnupdf will do a better job in the future. Or .. pdftohtml as a single app. http://sourceforge.net/projects/pdftohtml/files/ is some what abandon ware .. It was last update 2006. But it is included in the poppler-utils package. But debian will only work with poppler-utils 0.12 http://packages.debian.org/sv/squeeze/poppler-utils. Hm strange debian sid says 0.16.7 http://packages.debian.org/sv/sid/poppler-utils.
Anyway the newest is 0.18 http://poppler.freedesktop.org/ but it will not run under debian. So if someone have a another distro ubuntu for example https://launchpad.net/ubuntu/+source/poppler. It would interesting to see if it is the same html output.

What ever ...

The tool pdftohtml is generating lousy pictures . But it would be possible to extract better pictures with ghostscript http://www.perlmonks.org/?node_id=794904.

Pasting in the most imported stuff in case the thread will be removed ...

    For PDF to JPG (or any other raster image format like PNG or TIFF), you could use GhostScript to do the conversion:

    $ gs -q -dBATCH -dNOPAUSE -sDEVICE=jpeg -dJPEGQ88 -r150 -sOutputFile=i +mg%d.jpg input.pdf
    [download]

    This would create as many images (img1.jpg to imgN.jpg) as there are pages in the PDF file.  -r is the resolution in dpi (150dpi would create an image size of 1240x1754 for A4 paper size), and -dJPEGQ is the quality factor (up to 100).

    Unfortunately, this doesn't do any anti-aliasing, so the fonts typically look rather ragged...  You can work around that problem by doing the anti-aliasing yourself; which means, you'd have to oversample while rendering from PDF to raster (e.g. by a factor of 4, i.e. 600dpi) and then downsample with an appropriate filter.

    ImageMagick's convert can be used for the latter. The complete sequence of steps would be:

    $ gs -q -dBATCH -dNOPAUSE -sDEVICE=jpeg -dJPEGQ88 -r600 -sOutputFile=i +mg%d.jpg input.pdf $ for img in img*.jpg ; do convert $img -filter Lanczos -resize 25% -q +uality 90 out_$img ; done
    [download]

    The resulting anti-aliased images out_img*.jpg would then have 150dpi resolution.

    In case you have the non-/usr/bin-namespace-polluting sister GraphicsMagick installed (instead of ImageMagick), the command would be gm convert ...

    (Those who hold a degree in Signal Processing - or have come in contact with filter design in some other context - might want to take a look at the list of filters to choose from — in case of doubt, stick with Lanczos or Kaiser for somewhat sharper, or Gaussian or Cubic for somewhat softer results.)

    Also, there's documentation - well hidden from daylight - under /usr/share/doc/ghostscript/Devices.htm, which explains what options are available with the individual Ghostscript output devices (you usually need to have another package installed (e.g. ghostscript-doc on Debian/Ubuntu) to have that file).
I have not tested this my self.

Does anyone know what was the outcome from Andreas Gohr attempt?  http://www.freelists.org/post/dokuwiki/dokuwiki2html
This post was edited on 2012-02-24, 22:08 by pernils.
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Page:  1  2  next 
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Current time: 2019-06-25, 22:25:12 (UTC +02:00)