I am assembling image sequences, each sequence consisting of 1-5K png images. Each sequence is then subject to a large number of image manipulations. These manipulations are identical for each image, though may be slightly different from sequence to sequence. I wish to automate this whole operation. I can automate all the image manipulations using tools I have (PaintShop Photo Pro, IrfanView32, among others). The problem I have is automating the first step - the assembly of the images initially.
The images are produced from a tool, written in Java. There is no access to the source for this tool. In addition the tool was written in a GUI style derived in the Unix world. The implications of this are that normal Windows shortcuts are not necessarily recognised by the tool (eg Alt-F for the file menu; some buttons do not have shortcuts; etc). The tool provides two windows - a control window and an image window.
The sequence of actions I need to carry out to derive the images is as follows:
Initial steps (no automation needed).
Run tool
Load an initialisation file from the control window
Use the image window to setup the image full screen at the required magnification
Load a log file from the control window (format not available outside the tool)
The repetitive steps are:
Press a button in the image window to generate the image
Enter a file name in the resultant dialog box. This file name will need to have a root applicable to the sequence plus a unique increasing number (5 digit in string form) specific to the image.
Press a button in the control window to advance the log file
One final twist - the only way of determining the end of the sequence is that the tool indicates the end of log file by disabling the button on the control window. There is no other indication of EOF readily available.
My first thought was to use Microsoft's Powershell, but my limited understanding of that tool suggests that the Unix/Windows/GUI incompatibilites and the lack of availability of the java objects, precludes this approach.
My environment is Windows 7 Ultimate 64; development tools available to me are Delphi XE, 2006, 7; there are a number of other languages installed (Java, Python, Haskell).
What approaches and/or tools will enable me to automate this task. As a sole developer, my preference is for free or cheap tools.
AutoHotkey is a powerful tool which can fit your needs.
Related
I am using Ghostscript to convert pdf1.3 to pdf/a-1b using this command:
gs -dPDFA -dBATCH -dNOPAUSE -dNOOUTERSAVE -sColorConversionStrategy=sRGB -sDEVICE=pdfwrite -sOutputFile=output.pdf PDFA_def.ps input.pdf
The PDFA_def.ps is customized to use the srgb icc profile. Except that change it is the standard def file which comes with GS 9.26.
Now comes the tricky part:
1- running this conversion locally on a ubuntu 18.10, GS 9.26 it works fine an i get a valid pdf/a
2- running the same command in a docker container (ubuntu 18.10. GS 9.26) creates a pdf/a as well, which is considered to be valid
However, in the first scenario I can process the file using mustang (https://github.com/ZUGFeRD/mustangproject) to create a valid electronic invoice. In the second scenario (docker container) this fails, since the file is not considered to be valid pdf by mustang.
checking both pdf files I would have expected them to be identical since i am running the same converison on it. However they are not. The PDF create in the dockerfile is 10 bytes smaller and shows some different metainformation in the file itself.
I suspect that there must be some "hidden depdencies" that make GS to act different on my host system compared to a docker container, but it feels entirely wrong and I am running out of means to debug further.
Does anyone know, wether GS has some more depdencies that might cause the same command to produce different results?
The answer is 'maybe'. It depends on how Ghostscript was built for starters.
I assume you are using a package, and not building from source yourself. In which case there are a number of dependencies including; FreeType, LibJPEG, JBIG2dec, LibTIFF, JPEG-XR, LCMS2, LibPNG, OpenJPEG, Expat, zlib, potentially IJS, CUPS and X-Windows, depending on what devices were built in.
Any or all of these could be system shared libraries instead of being built using the specific version shipped by Artifex. They could also be different versions on the two systems.
That said, I think its 'unlikely' that this is your problem. However, without seeing the PDF files I can't tell you why there is a difference. Differences in the metadata are to be expected, since that includes a date/time stamp.
I'd really need to see examples of the original and the two output PDF files to be able to comment further.
[Edit]
Looking at the files they have been produced compressed (unsurprisingly) which can obviously lead to differences in size if there are small differences in the input streams. So the first task was to decompress the files.
That done I see there are, essentially, no differences between them. One of the operating systems is using a time zone 7 hours behind UTC, the other is in UTC so where one of the systems is time stamping with (eg)
2019-04-26T19:49:01Z
The other is using
2019-04-26T12:51:35-07:00
So instead of Z (for UTC) you get -07:00 which is where the extra 10 bytes are coming from. Other than that, the Unique IDs are (as you would imagine) different, the Length values for the streams are different for the streams containing dates, and the startxref is different because the streams are different lengths.
Both files claim to be compatible with PDF/A-1b. In short I can see no real differences between them. Since you are using a tool to further process the files, I'd suggest you try taking the PDF file from your working system and try processing it on the non-working system, and vice versa, it seems to me that the problem may be the later processing rather than the PDF file itself. Perhaps you have different versions of that tool on the two systems.
For what it may be worth, Ghostscript can be induced into creating a ZUGFeRD file directly, see this bug report and this commit to the repository.
I have a large application to manage consisting of of three or four executables and as many as fifty .dlls. Many of the source code files are shared across many of the projects.
The problem is a familiar one to many of us - if I change some source code I want to be able to identify which of the binaries will change and, therefore, what it is appropriate to retest.
A simple approach would be simply to compare file sizes. That is an 80% acceptable solution, but there is at least a theoretical possibility of missing something. Secondly, it gives me very little indication as to WHAT has changed; It would be ideal to get some form of report on this so I can then filter out irrelevant (e.g. dates/versions copyrights etc..)
On the plus side :
all my .dcus are in a row - I mean they are all built into a single folder
the build is controlled by a script (.bat)(easy, for example, to emit .obj files if that helps)
svn makes it easy to collect together any (two) revisions for comparison
On the minus side
There is no policy to include all used units in all projects; some units get included because they are on a search path.
Just knowing that a changed unit is used/compiled by a project is not sufficient proof that the binary is affected.
Before I begin writing some code to solve the problem I would like to ask the panel what suggestions they might have as to how to approach this.
The rules of StackOverflow forbid me to ask for recommended software, but if anyone has any positive experiences of continuous integration tools that would help - great
I am open to any suggestion or observation that is relevant in this context.
It seems to me that your question boils down to knowing which units are contained in your various executables. Since you are using search paths, it will be hard for you to work this out ahead of time. The most robust way to find out is to consult the .map file that the compiler emits. This contains a list of all units contained in your executable.
Once you know which units are contained in each executable, you need to know whether or not anything has changed in those units. That information is contained in your revision control system. Put this all together and you have the information that you need.
Of course, just because the source code for a unit has changed, you might argue that re-testing is not needed. Perhaps the only change made was the version, or the date in a copyright label or some such. But it is asking too much to be able to ask a computer to make such a judgement. At some point you need a human to step up and take responsibility.
What is odd about this though is that you are asking the question at all. It seems to me to be enormously risky to attempt partial testing. I cannot understand why you don't simply retest the entire product.
After using it for > 10 years for commercial in-house and freelancer work in large projects, I can recommend to try Apache Ant. It is a build tool which supports dependencies, and has many very helpful features.
Apache Ant also integrates nicely with CI tools such as Hudson/Jenkins, Bamboo etc.
Another suggestion - based on experience with Maven - is to design the general software architecture as modular as possible. If modules (single or multiple source or DCU files in one directory) use a version number in the directory name as a version number, it is possible to control exactly how application are composed from these modules.
If you want to program such a tool yourself the approach would be something like this:
First you need to detect wheter there were any changes made to seperate source files. As you already figured out comparing the file size is bad idea as the file size can stay the same despite lots of changes made to it (as long as there is same amount of text in pas file its size won't change). So instead you could check the last modification time for specific file or create some hash value like MD5 hash for comparison (can be quite slow).
Then you need to generate yourself a dependancy tree which will tell you which files are used for which project/subproject.
Finally based on changes detected in seperate files you check the dependancy tree to see which projects needs to be recompiled.
The problem of such approach is that you would probably have to update the dependancy tree manually each time when new unit is added to the project or an existing one is removed from the project.
But the best way would be to go and use some version controll software istead of reinventing the wheel. I myself like the way how GIT works and I belive that with proper implementation of GIT into the project mannager itself could be quite powerfull do to GIT support of branching/subbranching (each project is its own branch, each version of your software can be its own subbranch).
Now latest version of Delphi does have GIT integration done though SVN but this unfortunately limits some of best GIT functionality. So if you maybe decide to go and integrate GIT support directly into Delphi I'm first in line to use it.
I'd like to know if it is possible to select a typeface, font size and be able to use it right away during runtime in an XNA application.
If it isn't possible using built-in runtime methods, maybe it's easier (or better, or faster) to do it using some automation software (like autoit) to create spritefont file in the background, and be able to use it afterwards in an XNA app without restarting the app?
I'm going to use this mainly on my own computer for testing and picking fonts, so I'm okay if it requires full VS installation along with XNA framework and any other stuff.
Easy put, it can be done, but you have to use WinForms, link to tutorial in order to load spritefonts. You could do it simpler, by making a couple of spritefonts before you do anything (or create spritefonts for every font you have and add them to the content). This is so, because of how XNA handles spritefonts. As you've seen, SpriteFonts are basically an xml file. This is not how the final binaries are. The final binaries are images containing every character in the font you selected at that size. That way, the gamer doesn't have to have the font installed in order to play your game, and therefore you can do some awesome stuff with fonts and the user can't use that font (unless he rips it).
I have not yet found a tutorial for winforms and spritefonts, but I suppose that the model version needs only a little modification for it to work with spritefonts.
What solutions are there for working on a LaTeX document on both Windows and Linux?
It's a large document, and I will be working daily on both platforms so compatibility is essential if it's two different pieces of software.
Bonus points for a solution that includes easy previewing.
Writing text is not very different from writing software. Similar management techniques apply when scaling up.
Modularity: Split the document to smaller pieces e.g. a separate .tex file for each chapter. I also like to keep the preamble and other LaTeX set-up separate from the body text. My chapter files themselves just have the body text with some markup but do not define any new commands.
Source control: Keep all the source files in a version control tool such as subversion. Transfer files between systems using the tool.
Builds: Have a Makefile or similar to control the build process: it should be consistent and repeatable. Build regularly and fix build problems as soon as possible. If you want easy previews, you can set up a Makefile rule to launch e.g. a PDF viewer after the target PDF has been compiled.
Editing: Use whatever you're compatible with. It does not matter that much, though some good advice has been given by other answerers.
Communication: If there's more than one person working on the same stuff, no tool is a substitute for interpersonal communication.
TeXworks is a new cross-platform TeX editor with a built-in PDF preview that has source-output synchronisation. Click in the source to go to the matching part in the output, and vice versa. It's not the most feature-rich editor, by design, but the simplicity/power trade-off is just right, in my opinion.
I've used Emacs and its AucTeX mode, which is great for editing, as it has a set of very consistent shortcuts to insert many common commands and environments. There are also preview modes that display maths graphically in the Emacs window but I haven't used them.
As with VIM, there's a learning curve of course.
Unlike Legoolas, I'd advise for direct-to-PDF compilation using pdfTeX, but maybe Windows/Linux doesn't have a PDF viewer that automatically reloads the file? I'd be surprised if so (I use Skim on Mac). Check if your viewer supports synctex, as it's quite handy to navigate from PDF to source and back, without the cons of pdfsync.
To compile, my tool of choice is latexmk which is included in TeXlive. It completely automates the build, and can watch the .tex source to rebuild automatically.
Try LyX – The Document Processor, a "What You See Is What You Mean" editor for LaTeX.
Eclipse with its TeXlipse plugin should solve the IDE problem. More important are, however, issues like using only fonts that are available or installable on both platforms.
For previewing I am using Emacs with its Preview Latex feature in the AucTeX package.
For windows, you can use the TeXnicCenter, that is one of the best IDE for windows.
For Linux, you can use simply use Kile (it is possible to use kile with KDE on CygWin, but it is not the perfect solution).
There is no problem to switch from one IDE to another one (since you just save the .tex file and nothing else)
It also exists some cross-platform IDE, but I do not know them:
TeXmaker
TeXmakerX: a fork from TeXmaker
Since you'll probably not want to change text editor from whatever you usually use just for editing LaTeX docs (unless you use an editor which can't do syntax highlighting for LaTeX as well as whatever else you code/write in it), I'd recommend the simple following set of tools:
Whatever text editor you are used to, as long as it can highlight LaTeX markup. If it can't, then find a better editor for using with everything you do!.
Install MikTeX or TeXLive and just use the DVI viewer which comes with them by double-clicking on your DVI file. This will automatically update whenever the dvi file is changed by your editing of the latex file and re-creating the output.
I use Emacs as my text editor of choice, on both Linux and Windows. Setting up some scripts or makefiles to build the latex document when I hit a key is pretty easy, and fits in with everything else I use Emacs for nicely.
Other cross-platform options (many of which have already been mentioned by others in this thread):
LyX
TeXlispse for Eclipse
I've used VIM, combined with the VIM-LaTeX plugin, with great success. It does have a bit of a learning curve though.
Gummi is the best LaTeX editor. It is a free, open source, program written in python, featuring a live preview pane.
http://gummi.midnightcoding.org/
e4 http://gummi.midnightcoding.org/wp-content/uploads/20091012-1large(1).png
Get your work in some kind of version control system, then when you move from computer to computer you just update from a central server and its just like you left it.
It doesn't matter about the IDE, as you are saving just the .tex file, as noted above. If you want to use the same editor though, for the sake of coherency, use texmaker.
I use version control, and just use MikTex/WinEDT on Windows and TexShop on the mac.
IF your document doesn't compile on both, you're probably forgetting to keep the two directories synchronized or use funky commands, I like the sanity checks of knowing that it "compiles" cleanly on two platforms.
I use some text editor, and then I have a cron job that does a compile hourly from my source control.
Tex files are just text. I would recommend using a version control system (you should be using that anyway) to keep the source in sync. You can then use any (or different) editors on each system, e.g. Kile for linux and winEdt for windows. Both com with nice viewrs.
For a simple solution for the source control that just works with minimum knowledge and hassle, consider dropbox.
Revisiting my own question after quite a few years, I thought I'd add
https://www.writelatex.com/
not strictly what I had in mind, but have used it for collaborative writing
An excellent multiplatform LaTeX IDE is Texmaker.
For Debian or Ubuntu, I made a tutorial easy to follow: Install LaTeX on Ubuntu or Debian. This tutorial explains how to install LaTeX on Debian or Ubuntu and how to create your first PDF.
What Windows code editors allow the use of elastic tabstops, either natively or through a plugin?
I know about a gedit plugin, but it only works on Linux.
Code Browser may be the first for windows. I would love to see this feature as a plugin for other editors as well.
I did quite a bit of googling trying to find this answer. There are plenty of people asking for it:
http://developers.slashdot.org/comments.pl?sid=414610&cid=21996944
http://www.arguingwithmyself.com/archives/75-the-biggest-feature-your-editor-is-missing
http://intype.info/blog/screencast-parser-in-editor/#comment-221
http://codewords.wordpress.com/2006/10/16/eclipses-achilles-heel/
just to name a few...
so I don't think one exists yet, sorry :(
Code Browser supports elastic tabstops, but it appears to be the only thing for Windows that currently supports it. Unfortunately, it has an unusual UI which may render it unsuitable for multi-person projects, and may even make it difficult for you to use even if no other editors are involved.
According to the elastic tabtops website, he's working on plugins for eclipse and Visual Studio 2010 (though the Eclipse plugin is stalled pending a bugfix, and jedit should support elastic tabstops in an upcoming version.
Finally, though this probably isn't an option, you could try running an x server (such as Cygwin/X or Xming on your Windows computer and ssh into a Linux client (either a virtual machine or another computer) to run Gedit. This approach has many problems though: you need to keep your files on a separate computer (perhaps using Dropbox to keep them in sync), X over SSH is notoriously slow, and you need either another computer or a virtual machine.
XMLQuire is an XML editor developed for windows to showcase virtual formatting. This concept goes a step further than elastic tabstops, indentation is simply a function of the position of the preceding line-feed character and the nesting level and context assessed by the parser:
It's the XML parser that determines the nesting level and therefore the required indentation, there's no reformat key or tab key to press, the XML formatting just reflows as you edit, drag and drop etc.
This means that XML is always properly indented, but without leading tabs or spaces. The concept should also work for more conventional code (except for languages like F# that exploit whitespace), but this has not yet been tried out.
Note that, unlike elastic tabstops, virtual formatting only works from the left-margin and only uses the parser context. The parser context is more than just about nesting level though, factors such as mixed content, node-type, length of parent element name and attribute name all come into the equation. This allows alignment of attributes and attribute values that occur on new lines also (as shown).
Word-wrapped text naturally just fits to the indentation scheme. If further text formatting is required then space characters are added by the user in the conventional way.
As with elastic tabstops there's a potential issue when virtually formatted text is opened in a more conventional editor. However, because no characters have been added for XML formatting (it was all virtual), conventional editors can simply apply conventional formatting according to the settings for that editor, uses tabs or spaces.
Here's a elastic tabstop plugin for Visual Studio 2010 by ferveo (Ramunas Geciauskas):
http://visualstudiogallery.msdn.microsoft.com/ccff2b55-201f-4263-aea5-3e66024d6c0e
Another option is jedit which has already added support for elastic tabstops. It is available on Windows, Linux, OS X, and Unix.
The problem is that only a few toolkits/platforms have text widgets that offer the ability to set non-uniform tabstops on different lines. To my knowledge, those toolkits/platforms are Java Swing (used by the demo on the elastic tabstops page), GTK (used by Gedit and the Gedit plugin), and apparently the new version of Visual Studio (VS 2010).
Expect to (eventually) see more developments on all of those platforms.
Textadept has an elastic tabstop plugin.
Atom also has a plugin.