I have received a BigTiff file with scientific data which can't be read properly with ImageJ/Fiji. There seems to be a problem with LibTiff and the StripOffsets tag.
The only options I found are using LibTiff directly (probably bad, if I'm not sure if the issue is caused by LibTiff itself) and ImageJ/Fiji.
Is there a way to have a "higher level" access (i. e. no hex editor) on the provided data?
E. g. some library or tool to "debug" the file and change properties on the fly?
I had the same problem and in my case when the files were too big for the viewers they sent this message of problems with the StripOffsets tag. Now I use my IIPImage viewer, that I builded with libtiff 4.0.3 (with BigTIFF support), to view my file, but I still am in search for a good viewer for huge TIFF files.
Related
This is the problem:
(On Linux Slackware64) I compiled Inkscape (0.92.3) and found that exporting to PNG doesn't work. An indication on the terminal tells me:
libpng warning: Application built with libpng-1.6.16 but running with 1.5.13
First reaction was to list the linked libraries using ldd. Indeed, both libpng-1.6.16 and libpng-1.5.13 are listed as necessary.
So, I suspected that some of the other libraries was requiring libpng-1.5.13. I made a small Python program which takes all the libraries (except the libpngs) and applies ldd to each of them. None of them listed libpng15. What now? I suspect that if any of the secondary libraries needed libpng15, it would be listed here, but, just in case I made the search recursive. No luck.
So it was, apparently, inkscape itself requesting the old version. A simple search in all files in the search tree only showed the string 'png15' in the viewer and actual inkscape executable.
There are probably older programs of mine still linked with png15, so I probably want to keep that version around.
Most, if not all references on the net mentioning this error (or similar) refer to programs with very old pnglibs (1.2.4x) trying to use a newer version, but here it's the other way around.
libpng-config --version reports 1.6.16
Any suggestion how to identify the source of this problem? Particularly why inkscape included the old libpng?
I am looking for an option for converting my .as ActionScript3 files to binary format before distribution. I tried mxmlc and compc but both are converting source to bytecode which is reversible. Is there any way to hide your source code completely?
thanks in advance
BB23850
As Flash Players can only read bytecodes, but not binary machine code, it is obvious you won't be able to do so. But there are other means of obfuscating your code from getting decoded easily.
If your target is to create stand-alone executable files, then consider SWFKit Pro or similar application. SWFKit store swf as encrypted file, only decrypt when required.
Localizing with ICU recommends keeping localizable data in XLIFF format.
So I used GNU xgettext to extract strings to gettext format files, and then converted them to XLIFF files with po2xliff.
Finally I tried to use XLIFF To ICU ResourceBundle Format Converter to turn them into ICU resource format, before I found it not work. It complains the error:
The XLIFF document is invalid, please check it first:
Line 2, Column 68
Error: cvc-elt.1: Cannot find the declaration of element 'xliff'.
Almost the same error was reported years ago and is yet to be fixed.
Line 2 of the poor XLIFF file was:
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
Well, I edited the line in accordiance with example.xlf in Localizing with ICU page (there are lots of typos in example file), retried, and ended up with:
ERROR: java.lang.NullPointerException
So what's the best practice of localizing with ICU4C and XLIFF?
Considering that the XLIFF To ICU ResourceBundle Format Converter does not yet support XLIFF 1.2 (which has been around for many years) I would recommend to stay away from XLIFF and to use po files for localization. There are several localization tools that support po files: in the answers to this question and this one you will find a fairly large number of localization tools that handle po files, and new ones are still being developped (like this one).
Of course not every translator will be able or willing to handle po files, but the chances of getting your software localized are much better via po than by trying to go the XLIFF way.
I can't answer your question on the best practice for localizing with ICU4C and XLIFF, but I have seen the "The XLIFF document is invalid" error when I used the wrong version of the Java JDK while building the ICU resource.
On my system, I see the error when I use jdk1.7.0_67. Everything works fine if I use jdk1.6.0_45. This is with ICU 52.1. You might need to verify that you are using the correct JDK for the version of ICU you are using.
I'm using MathType to write mathematical expressions, which uses "MT Extra" font to do some extra symbols. MathType saves the equation in a .eps format, which I want to add to a Scribus document as an image.
Exporting to .pdf with "embed .eps files" option doesn't show the extra symbols written with the MT Extra font. Since Scribus works with Ghostscript, I believe I have to configure ghostscript to use MT Extra font. Am I right? How can I do that?
ThankYou for your time.
Thank you for your answer, #KenS. I'm using Windows. The font is embed, but I really can't understand (reading the ghostscript documentation) how to use the -I switch on ghostscript command line to include the font path. When I use GSView I can configure it in "Advanced configure" (using -sFONTPATH=c:\windows\fonts), and the .eps looks ok, but it doesn't change the behaviour of ghostscript when I insert the .eps into Scribus (and ghostscript is configured to be the ps interpreter). I don't know how to tell directly to ghostscript to include the fontpath. I'm sorry to ask you again, #KenS, and thank you again for your time.
If the font is embedded in the EPS file, then you don't need to do anything. If they are not then you should get a warning from Ghostscript that a font can't be found and a substitute is being used. If you get that warning then you need to add the font, otherwise you don't. Its poor practice not to embed fconts though.
Adding fonts to Ghostscript is documented in ghostpdl/gs/doc/Fonts.htm See Section 7 in particular.
Assuming you are on Linux you may, or may not, have a ROM file system, depending on how your distribution has chosen to package Ghostscript. If you are using a ROM file system then you will I think need to use the -I switch to include different font paths (again there is documentation on this). If you are not using a ROM file system, or the package already includes fonts on disk then its only necessary to follow the steps described in the documentation.
I have downloaded an open source project using graphviz c++ library, which visualizes and draws charts from or to dot files. But unfortunately, I deleted it from my computer.
I really look forward to finding it because it is exactly what I need. I remember there are well-done encapsulated classes such as GVGraph, GVNode, GVEdge and so on. Can anyone tell me where it is?
Maybe you can find it on the resources page of graphviz.