I'm trying to find a way to compact Robohelp 8 projects so that when I upload a Webhelp documentation to a customer server it doesn't contain thousands of files. Is this possible? Any suggestions for compiling projects to a smaller size?
WebHelp isn't really "compiled". The generated WebHelp output has the same files as in the RoboHelpsource - the HTML pages, images, and baggage files you've included. The differences in the HTML pages include, for example, actual content instead of the User Defined Variables and Snippets in the source.
Plus there are a lot of HTML, XML, JavaScript and image files for navigation, index and glossary.
Adobe's info on those output files, specifically for RoboHelp 11: http://help.adobe.com/en_US/robohelp/robohtml/WS5b3ccc516d4fbf351e63e3d11aff59c2a0-7fb6.html
Related
We are in the 21st century and still there is no good way to tag photos and videos? There is always a dependency on some tool... Is there no way to make the file autonomous with respect to its tags?
Video files, for example, are not friendly to tags. some video formats do not allow tagging at all. Some tools keep the meta data in their own external representation and when you copy the original file to some new destination, the meta data of the file in the destination is lost. Also this metadata may only be seen by this proprietary tool and is not seen by other tools (e.g. tagging by Adobe products are not visible/searchable in Windows Explorer)
Is there a universal way to tag any file including video files so that
searching for files having a certain tag is possible in any tool
when a file is copied, the tags are transferred with it
when the file is edited in any tool and re-saved, the tags are not lost...?
There are no universal ways at this point, if there ever will be one.
Probaby the closest we got is file tagging provided by popular OSes based on a certain file systems' feature called 'forking'. By this means Windows and Mac provide an ability to easily add meta data (including keywords) to any file on the file system, without changing the file's content. One serious drawback of this feature is that it does not cross file-system's boundary, i.e. if you simply upload a file to the web, or copy it to a different type filesystem - the metadata will be lost. There are ways to copy such metadata but that requires consideration and use of appropriate tools.
I am building an internal project wiki for a group software development project. The project wiki is currently powered by VimWiki and I send the HTML files to both the project supervisor and each of the development team on a weekly basis. This keeps our Intellectual property secure and internal, but also organized and up to date. I would like to put diagram images into the wiki itself so that all diagrams and documentation can be accessed together with ease. I am however having trouble making the images transferable between systems. Does vimwiki give a way for image files to be embedded such that they can be transferred between systems? Ideally the solution would make it possible to transfer the output directory of the Vimwiki as a singular entity containing the HTML files and the image files.
I have tried reading the documentation on images in the vimwiki reference document. I have not had luck using local: or file: variants. The wiki reference states that local should convert the image links to a localized location based on the output directory of the HTML files, but it breaks my image when I use it.
I have currently in my file
{{file:/images/picture.png}}
I expect the system to be able to transfer the file between computers but it registers to an absolute link and also does not include the image directory in the output directory of the vimwikiAll2HTML command.
I know this is an old question, but try to use {{local:/images/picture.png}} instead. If you open :help vimwiki in Vim, you can find a part that says:
In Vim, "file:" and "local:" behave the same, i.e. you can use them with both
relative and absolute links. When converted to HTML, however, "file:" links
will become absolute links, while "local:" links become relative to the HTML
output directory. The latter can be useful if you copy your HTML files to
another computer.
I am editing kml files of maps of history and science of files that already appear on http://climateviewer.org/. I am editing them in Sublime text and/or Notepad since all I am doing is editing text, deleting extended data and switching links and references from my old web site MyReadingMapped to the new site which has far better technology. You can see images of the maps I made at http://climateviewer.org/myreadingmapped/
BTW, I am not a programmer or developer of software, but rather a retired marketing communications professional who understands just enough coding to make these changes and can do some html as well.
The problem I am having is that of the 30 or so files I have edited so far 4 have a parsing error that consistently involves closing a Placemark. Yet there appears to be nothing wrong with the code. I am testing the files by uploading them to Google Earth to get the error statements. And so far I have fixed many problems but I can't seem to solve this problem. Jim Lee, ClimateViewer's creator tells me to debug them.
How do I debug them and is it something I would be able to learn without formal training?
There are several tools available to debug a KML file, which is simply an XML file that must conform to rules of the KML specification. As an XML file, all start and end tags must match. In addition, the tags are case-sensitive.
The easiest trick is using a web browser to validate it. Simply rename the KML file to an XML file (rename .kml extension to .xml) then drag the .xml file onto the open web browser. Parsing errors will be identified with row and column number.
Next, you can upload the KML file to KML Validator to get a list of potential errors that need to be fixed or run the standalone command-line XmlValidator tool.
Additional tips to fix KML files are described here along with details about KML validation.
I want to parse a folder of template HTML files and cache (or buffer) them on build for later use in a web project. Basically I am trying to make it so when I build my project I dont need to take the HTML files with me when I upload the executable file.
I think maybe you are talking about embedding the html files in your binary?
If so the best way to do this that I've seen so far has been camlistores fileembed: https://code.google.com/p/camlistore/source/browse/pkg/fileembed/fileembed.go
See here for directions on use: https://groups.google.com/d/msg/golang-nuts/LQMv7Zsmsi0/8Aax1XSekjAJ
That thread has addtional info on other packages for this as well.
I need to create pdf reports in my app. I'm using asp.net mvc3. What's the best way to do this? I don't really want to use a reporting framework if i can avoid it, it's just a few reports, table layout, groupings, pagination possibly, totals, ability to merge pdfs into 1 pdf....any ideas? what would be ideal is if i could convert my html view into a pdf simply...
There is nothing built into .NET allowing to create PDF files. So you have two possibilities: write one yourself from scratch or use one that exists.
In case you decide to go with the second you may take a look at flying-saucer which along with ikvmc.exe could be used to convert XHTML files into PDF. I have blogged about some of the required steps in order to get this working.
Some possibilities:
I think you can do this with SQL Server reporting services (in SQL rather than a 3rd party reporting framework)
Low level PDF libraries that can be used: PDFSharp, iTextSharp.
You could print an html file to a postscript driver using word automation, then convert the PS to PDF via GhostScript