The failings of low-end consumer software, to typeset Math as (HTML) MathML.

One of the features which HTML5 has, and which many Web-browsers support, is the ability to typeset Mathematical formulae, which is known as ‘MathML’. Actually, MathML is an extension of XML, which also happens to be supported when inserted into HTML.

The “WiKiPedia” uses some such solution, partially because they need their formulae to look as sharp as possible at any resolution, but also, because they’d only have so much capacity, to store many, many image-files. In fact, the WiKiPedia uses a number of lossless techniques, to store sharp images as well as formulae. ( :1 )

But from a personal perspective, I’d appreciate a GUI, which allows me to export MathML. It’s fine to learn the syntax and code the HTML by hand, but in my life, the number of syntax-variations I’d need to invest to learn, would be almost as great, as the total number of software-packages I have installed, since each software-package, potentially uses yet-another syntax.

What I find however, is that if our software is open-source, very little of it will actually export to MathML. It would be very nice if we could get our Linux-based LaTeX engines, to export to this format, in a way that specifically preserves Math well. But what I find is, even though I posses a powerful GUI to help me manage various LaTeX renderings, that GUI being named “Kile”, that GUI relies back on a simple command-line tool named ‘latex2html’. Whatever that command-line outputs, that’s what all of Kile will output, if we tell it to render LaTeX specifically to HTML. ‘latex2html’ in turn, depends on ‘netpbm’, which counts as very old, legacy software.

One reason ‘latex2html’ will fail us, is the fact that in general, its intent is to render LaTeX, but not Math in any specific way. And so, just to posses the .TEX Files, will not guarantee a Linux user, that his resulting HTML will be stellar. ‘latex2html’ will generally output PNG Images, and will embed those images in the HTML File, on the premise that aside from the rasterization, PNG Format is lossless. Further, if the LaTeX code was generated by “wxMaxima”, using its ‘pdfLaTeX’ export format, we end up with incorrectly-aligned syntax, just because that dialect of LaTeX has been optimized by wxMaxima, for use in generating .PDF Files next.

(Updated 05/27/2018 : )

Continue reading The failings of low-end consumer software, to typeset Math as (HTML) MathML.

I’ve just custom-compiled ‘Aqsis’.

To give some context to this proclamation, I had written an earlier posting, about adapting the non-packaged software named ‘Ayam‘ to Debian / Stretch, that had worked just fine under Debian / Jessie. This is a GUI which constructs complex ‘Renderman‘-Compliant rendering instructions, in this case in the form of .RIB-Files, which in turn, ‘Aqsis’ can turn into 2D perspective views of 3D scenes, that have been software-rendered. OTOH, Ayam itself uses OpenGL and H/W rendering, for its GUI.

What I had found before, was that Ayam did not seem stable anymore under Debian / Stretch. I apologize for this assessment. Under close scrutiny, my computer has revealed, that it was really Aqsis giving the problems, not Ayam. Aqsis is a text-based tool in effect.

Ayam does not specifically need to be used with Aqsis to do its rendering. It can be set up to use other rendering-engines, most of which are quite expensive. Aqsis just happens to be the best Open-Source rendering-engine, whose language Ayam speaks. And at this point I’d say that Ayam is still quite stable, after all, under Debian / Stretch.

As is often the case with such troubles, I next sought to custom-compile Aqsis, to see whether doing so could get rid of its quirks. What were its quirks?

Finally, the only problem with Aqsis was and remains, that it cannot produce a real-time preview of the scene being edited, which it used to provide using a component-program named ‘piqsl’. And the reason why the packaged version of Aqsis does not have ‘piqsl’ under Debian / Stretch, is because this distribution of Linux has a very new ‘Boost’ library ( v1.62 ) , and the visual component to Aqsis, that could produce a display, still relies on the Qt4 libraries and their API, which have begun to bit-rot. The Qt4-specific code of Aqsis cannot parse the newest usage of the Boost libraries, and Debian maintainers have long since discovered this. They are shunning the use of ‘libqt4-dev’ and of ‘libqt4-opengl-dev’ to build any of their packages. So they were effectively forced to package a version of Aqsis, which was missing some important components.

(Updated 12/12/2017 … )

Continue reading I’ve just custom-compiled ‘Aqsis’.

Atomic Game Engine Installed – twice

One of the projects which I have recently undertaken, is to compile and install Atomic Game Engine, both on my Linux laptop ‘Klystron’, and on my Windows 7 machine ‘Mithral’. This was originally a closed platform, but has received renewed interest, because it is now available under the MIT license, which is a form of Open-Source licensing, more permissive than GPL v3 is.

This platform has the eventual capability, to deploy 3D applications and games, to Windows, OS/X, Linux, Android, iOS and WebGL recipient-platforms, while some forms of it will run under Windows and Linux, in my own experience.

I have to say though, that my ability to get the Linux version of this game-design platform working, was not due to my own prowess, but rather to the fact that the development team at Atomic Game Engine, provided dedicated and consistent technical support to me, every time I ran into a problem. I would guess they are rather tired of answering my many questions for the moment, so it is also good news, that both under Linux and Windows, my installations of this platform are complete – to my own satisfaction.

I have exported a 3D application to Android from my Windows platform, but have not reproduced this success under Linux, mainly because the platform requires that I specify where my Android SDK and where my Ant executable are located – sensibly – and I do not have any Android SDK presently, installed on ‘Klystron’. I do have the Android SDK installed on ‘Mithral’, which as I said is required, and so the export to Android worked there.

Installation under Windows was much more straightforward than it was under Linux, which is often the case, because the Windows version comes as an available binary SDK, while under Linux it still needs to be custom-compiled. And whenever we custom-compile anything, we can run into dependency issues.

One major issue I faced under Linux, was the fact that the Mono packages that are standard for my Debian distribution, are not adequate in what they provide, for development in C# to be enabled. And so what I needed to do, was to subscribe to another Mono repository, managed by Mono project, to upgrade my whole Mono installation, and after that, C# also worked.

So, Atomic Game Engine allows for 3D applications and games to be designed, using the languages C#, JavaScript, and TypeScript, according to my own experience… But, a C# Project cannot be exported for WebGL playing.

Also, I have discovered along the way, that We are no longer expected to install ‘Visual Studio 2015 Express’, but rather “Visual Studio 2015 Community Edition”, and in order to get C# support to work properly on my Windows 7 machine, I needed to do an in-place upgrade, from ‘VS Express’ to ‘VS Community’.

I am pleased that all the installation and upgrading seems to have gone well, and seems to have left me with no major reliability issues, either on ‘Klystron’ or on ‘Mithral’.

However, because the build of Mono now on ‘Klystron’ is non-standard, I cannot vouch for it in general. On my actual server-box ‘Phoenix’, I must choose to stick with the more conservative Mono packages, that are meant to go with Debian, because this box needs to run reliably 100% of the time. OTOH, on ‘Klystron’, I had nothing else depending on Mono, for which reason I was also willing to do the upgrade.



Getting Java / RAD support within the Open version of Eclipse

One type of question which some of my friends will ask me from time to time, is ‘Whether I am aware of any good IDEs these days’. This question arises from the knowledge, that writing source code just with a text editor, is not much fun, the fact that IDEs exist which enhance the programming experience, and finally, the memory from our distant past, of the fact that there exist IDEs which implement a kind of ‘RAD’ – a Rational Application Development – or a Rapid Application Development platform. This can sometimes conjure up pleasant memories of the days when Sun Microsystems was still in control of Java.

And so I have taken a minor step to explore this subject only today, and come to the following observations.

Java / RAD in the old days, was already based on ‘Swing‘. And Swing is a set of Java packages, which keep two things in sync: A code view, and a design view of our project. It was Swing which would update the code view, if we made changes graphically to our design view, and vice-versa.

Having understood that, the next thing people who use Linux might do – as I did – would be to install a number of Java Swing libraries from our package manager, and then to hope that we have what it takes to start building Java / RAD projects, the way we used to do it with ‘JBuilder‘. JBuilder was a proprietary, paid-for IDE, which back in the days of ‘Borland Inprise‘, possessed the components in a bundled way, not just to be an IDE, but to be an IDE with RAD capabilities.

But inevitably, we run into an impasse. Under Linux and entirely with Open Source software, we are likely to be using “Eclipse” as our IDE, and a version of it, which does not recognize that we have Swing packages installed – in our shared, non-proprietary Java folders. I do know that paid-for versions of Eclipse exist, which again bundle Java / RAD capabilities, but we might want to obtain those, without having to pay much money. So what can be done?

The answer that suits some use of Eclipse, lies in the fact that with any Linux Eclipse install, there exists a user-space install of extensions, similarly to how the Windows flavor of Eclipse, also has such a built-in mechanism to install extensions to this IDE itself. We find that in the Help menu, there is an entry named “Install New Software”. From there, we can specify a URL to download packages from, and we can extend, or possibly confuse, our Eclipse setup. But what we install from here under Linux does not ever use ‘root’, and thus only exists in our user / home directories.

There is a relevant URL which I just learned about, from which we can tell Eclipse to install extensions to itself:

And when we have typed in the URL, we can see a set of components available, which include 3 Swing components, plus the critically-important “Window Builder“. This Window Builder is the Eclipse extension, that actually maintains the two views. After we have installed all the relevant packages – because we often tell this wizard to install all the dependencies as well – we need to restart Eclipse. We may first have to acknowledge having to install non-signed packages.

Once this is done, under the New Projects list, we will see as the last menu entry, “Other”, referring to a miscellany of non-standard project types. And when we open that view, we will finally get to see our Swing subsection of New objects that we can create.

Doing so opens a specialized wizard, and sets up our Java / RAD project, which will eventually have a code view and a design view.

Now, the logical question does arise, of whether it did any good, to install Swing packages via the Linux package manager. Doing so places them into shared folders using root privileges, folders that are not even specific to one Java compiler used. I have run into situations before, in which Java projects designed by other programmers did not initially recognize, that these shared Java libraries even existed. This has required some workarounds in my past.

Using Eclipse, the fact is that these packages will not show up in the graphical browsers /  wizards.

But I think that this is one reason, to install all 4 components offered by the URL above, to make certain object types visible in the IDE wizard. After one has created a basic project with the code and design views, I think the next thing to try, would be just to add the ‘import‘ statements to the code view, that are meant to pull in the Swing packages we think we need, and then to see, whether the design view renders them correctly.

Whether it does so or not, next depends on the separate question, of whether All Swing packages are in fact compatible with the Google Window Builder. And even though Swing should implement a standard interface, depending on what we are trying to do, the answer might still be ‘No’.

It would be necessary to link our project to the desired JAR File explicitly, in a way that states its location in the shared, root File System… In that case, we would click on the IDE Menu, “File -> Import”. And in the window which appears, instead of choosing “Plug-Ins And Fragments”, we could choose “General -> File System”… And under Linux we would choose the folder ‘/usr/share/java‘, so that in the subsequent view, we can select the required JAR Files, knowing that they will be copied.

Then, we would right-click on the project we want to build, and click on Properties, which opens another window, from which we would choose “Java Build Path -> Libraries” …


(Edit : ) It is entirely unproven, whether externally-supplied Swing libraries can be made to work properly, with Google Window Builder. What Google has done, is to name the Swing components of its Window Builder, as offering a ‘JPanel‘, a ‘JFrame‘, a ‘JApplet‘ etc., so that the naming of classes will not interfere with generic Swing class names. Hence, if we were to try to use Swing classes provided by the Linux package manager as stated before, first of all those would have dependencies on one or more base libraries, also located in ‘/usr/share/java‘, which would not only require that the ‘import‘ declarations be put into our Java source file, but also that the libraries be listed after the libraries that already belong to Window Builder, within the link order defined in the ‘Java Build Path‘.

The ultimate success we would want to see, would be that the Component Palette belonging to Window Builder, should offer us additional components, other than J-this or J-that. But the mere fact that the naming of classes has been separated, suggests the possibility that these external components will not be recognized by Window Builder at all.

One quick test a user could perform, would take into account the observation that Window Builder source code tends to import one specific package, such as ‘javax.swing.jframe‘. After we have appended the desired libraries to the Java Build Path, base library first, we could try to declare something that generic Swing projects frequently used:

import javax.swing.*;

This declaration should either work, or crash Window Builder.

(Answer : ) Doing so simply causes Window Builder to crash temporarily, until the offending declaration is removed from the code view. That is all.