Four years of Aegisub

Today it's just about four years since Aegisub was first conceived.

It was on the 17th of June 2005 in a private channel on the ChatSociety IRC network. We were discussing the various problems with making advanced typesetting in ASS subtitles and how poor the tools generally were.

The original name was Visual SSA, and it was originally just intended to be a tool to assist in doing typesetting. Yes, the visual typesetting tools we only got implemented somewhat in the more recent versions was the original goal of the program. General-purpose subtitle editing wasn't it.

It wasn't many days into development before video was shown.



At that point, showing video was all it did. As things went, basic loading, editing and saving of subtitles was added soon, and the interface started looking a lot like the current versions, but still not quite.



The important part here is what's above the subtitle editing area: Where the audio box sits today is space for a toolbox. The intention was to add visual typesetting tools there.

Of course, that never happened, and audio took over that place instead. In fact, the goal turned towards making a replacement for the subtitling program Medusa, which was popular then. (A few people are still using it today!) This is where the name of Aegisub comes from: Aegis is the shield of Athena, upon which Medusa's head was put after she was slain by Perseus.


Development went on, features were added, slowly we got more testers and went towards a relatively stable version. On December 27 2005, version "1.00 beta" was released, just a little more than 6 months after the first idea.

Development continued with regular "beta" releases.

We had the notorious version 1.06 with the "movax bug" in the installer: The installation script had a typo in it, which caused it to, instead of adding Aegisub to Windows' Add/Remove Programs list, clear most of the data for the list. After it was discovered, 1.06a was quickly released fixing just that problem, though several people had already been hit by it.

It was first at version 1.07 we went open source. At this point, development still happened on a private SVN server with no public access, and all bug reports and feature requests were taken on the forum. The source for both 1.07, 1.08 and 1.09 was distributed as part of the installer package, there was still no public repository.

However, soon after 1.09, we moved to a new host for source code repository, which allowed us to open up the repository for anonymous read access. It was also around this time we got a real bug tracker. The 1.10 beta was the first version released under fully open development, that happened on August 7 2006.


If you compare the screenshots of 1.00 and 1.10, you'll see not much had changed. There's a large number of changes you first notice when you dive into the menus, of course, but compared to what has changed since then, it's just tiny.

After 1.10, the plan first was to release 1.11, and that should be done before the end of the year. First, things went pretty smooth, but then new huge features started slipping in, they weren't stable, and thus the release slipped. Shortly after the new year passed, we decided the changes were big enough that we'd now call it 2.00 instead.

Now, the rest is almost history, but not quite.

Visual typesetting finally got added, the thing Aegisub (then Visual SSA) was first intended for, and pre-release upon pre-release was put out. In the end we decided there were far too many versions called "2.00 pre-release" to make releasing "2.00 final" feasible without confusing everyone, so we instead decided 2.2.0 would be the first version of Aegisub labelled as "stable", and we would release 2.1.x versions until then.

2.1.6 was released on November 26, 2008, which is soon 7 months ago. The good news: 2.1.7 is almost ready and you can expect it within a few days, and version 2.2.0 should be less than a month away!


The installer for Aegisub 1.00 was 2.82 MB, the installer for Aegisub 2.1.7 on Windows will be close to 24 MB. We've come a long way since that day in June 2005.

Read More...

Kumaji explained

Kumaji is an advanced subtitle rendering engine, in development.

At the time of writing this, Kumaji does not render any subtitles whatsoever and is in general in a very early stage.

There are several reasons I started the Kumaji project, I will try to cover them in this post.

The name

First what does "Kumaji" even mean? It's derived from Japanese where it would be written クマジ. If you reverse that, you get ジマク, "jimaku" (字幕), which means subtitles. Also, Kumaji can be understood as 熊字, "bear" + "writing", hence Kumaji has a bear for a mascot! (Lots of people have suggested using Pedobear, this is wrong, I don't want to have that association.)

"Kumaji" should be reasonably easy to pronounce for most people and as far as I know it doesn't have the potential to offend people, like "libass" might have. The name is also format-agnostic like the actual renderer will be.

The goals

The key goals are:

1. Portable code without sacrificing compatibility


2. Maintainable and hackable code


3. Speed


4. Flexibility

Portability is the first and foremost goal. All current subtitle renderers have major problems with this. Those that do compile and work on multiple platforms (libass and the abandoned asa) are strongly tied to details of text and font handling on UNIX-like systems, which means they fail on Windows and Mac platforms because those have much different ways of handling fonts which FontConfig doesn't wrap properly or over-complicates. The result is very sub-optimal. VSFilter depends on not just Win32 (and Wine doesn't implement everything it requires yet) as well as MFC and COM. Perian's subtitle rendrer is Objective-C and entirely dependant on Cocoa text API's. Kumaji will achieve portability by plugging in platform-specific code where appropriate. The motto would be doing the right thing on each platform, whatever the cost.

Maintainable and hackable code is important. It must be possible to jump into the code without having a great understanding of the entire system beforehand, and it must be possible to learn good techniques from reading the code. The code must be well-commented or self-explanatory all around. (Portions of the code with poor, little or no explanations should be treated as bugs and reported.) VSFilter is a prime example of how I do not want the code to end up.

Speed is obviously important, to a certain degree. Reasonable subtitle scripts should render in realtime so Kumaji can be used for softsubbing. This may mean writing some critical routines in multiple versions optimised for different systems, using SIMD intrinsics or hand-optimised assembly code. However, good algorithms and data structures still take priority over SIMD and assembly tricks.

Finally, Kumaji must be flexible. It should be possible to implement support for new subtitle formats without providing more than a parser for them. If a format requires special rendering support not present, it must be possible to add that without taking the entire system apart and jeopardising the previous goals. It should also be possible to use Kumaji as a framework to write custom special-purpose renderers. For example, one can imagine creating a Lua interface for Kumaji's internal functions and use that for scripting advanced karaoke effects.

Help wanted!

Currently, Kumaji is pretty much my own pet project, but I would really like to have some help. What's needed right now is data structure design. If you want to help I expect you to have some knowledge of digital typography, the intricacies of Unicode complex scripts and the Bidi algorithm, OpenType, as well as general data structure and algorithm design. Or you should be have or be able to take an interest in those topics and read lots and lots about them! (It's interesting stuff, really!)

Kumaji is being written in C++ using just the STL (no TR1 libraries, boost or otherwise) so if you want to help reviewing or writing code you should be familiar with that.

The project is being hosted at SourceForge.net under the name kumaji.

Read More...

Bug tracker back!

Yep, we got the bug tracker back online!

Unfortunately, since we only had an old back-up, about 6 weeks of activity was lost. The URL is the same as before and should work everywhere already.

Read More...

Don't use \fad on fades to black

Dear typesetters,

I have seen this countless times. Every time, it has bothered me. Please, don't do it anymore.

When the screen fades to black (or white, or any other solid colour, for that matter), DON'T use the \fad tag to fade the text along with it. When you use \fad, you're making the text translucent, and not darker. The result is that it will blend with the background - including all the usual associated bugs if you have borders and shadows - and get somewhat darker because the background itself is getting darker - it just won't get as dark as it SHOULD be, and the visual effect is that the text is getting brighter, relative to the background.

Original

With \fad

With \t(\c)

As you can see above, the CORRECT way to deal with this is by using \t to animate the colour (all relevant ones) to black (or whichever colour the screen is fading to). Also note that the background can be seen through the text in the \fad() case, which is not the correct behavior.

Keep in mind, though, \t(\c) is significantly slower than \fad() on VSFilter, so you might have softsub issues, depending on how complex is your text.

Read More...

If programming languages were religions: the aftermath

Until December 15 2008, aegisub.net would typically get ~350 hits per day. Between December 16 and 19, it got a total of 266 thousand hits, thanks to the "If programming languages were religions..." post. So, first of all: Thanks, everybody! All feedback, positive and negative, was greatly appreciated.

First it was put on Digg. Then on reddit. Then, to my great surprise, on Slashdot... and on slashdot.jp. Stumbleupon. And even on one of my favourite blogs, Pharyngula. It was linked on many IRC channels and blogs around the Internet... Several of my friends wrote to tell me that they had seen it linked in some internal forum or mail list. I never expected this kind of reaction!

So here's the basic rundown on all the comments that I saw: most Muslims (that manifested their opinion regarding it, at least) thought that it was funny, and didn't think that it was insulting. Several others thought that it was very offensive. Lots of people thought that I was a Python fanboy (C++ is my actual favourite language, although it's possible that Haskell will take its place as I learn more about it), or a Microsoft hater (hey, I use Vista and Visual C++). Since I got accused of being a Jew by at least 3 different people, let me get this straight: I'm an atheist.

There were many complaints about "missing" languages, or "stereotyping". The list was never meant to be exhaustive, nor was it meant to be perfectly accurate - it's meant to be a JOKE. It's SATIRE. I KNOW that Satanism isn't really about selling souls, and that some of the matches aren't perfect. Also, the reason why languages such as Pascal, Fortran and Smalltalk didn't make it to the list was because I couldn't think of anything funny to say about them. The single most common observation was that assembly should be atheism - I actually WROTE that at a point, but I removed from the final post because I felt that it would end up being biased, one way or the other, and because atheism isn't a religion (or lack of one, for that matter).

If you thought that the original article was funny, I suggest you to read through the comments, both on the article and on the links above - there are some very funny suggestions on those, both for languages that I covered and also for many that I didn't mention.

P.S.: Some people seemed to take issue at me calling C restrictive. I obviously didn't mean that it's restrictive in a "what can you implement with it" sense, but rather in a "to what level can you abstract with it" sense.

Read More...

If programming languages were religions...

And now, for some off-topic:

"If programming languages were religions"
(Inspired by "If programming languages were cars")

C would be Judaism - it's old and restrictive, but most of the world is familiar with its laws and respects them. The catch is, you can't convert into it - you're either into it from the start, or you will think that it's insanity. Also, when things go wrong, many people are willing to blame the problems of the world on it.

Java would be Fundamentalist Christianity - it's theoretically based on C, but it voids so many of the old laws that it doesn't feel like the original at all. Instead, it adds its own set of rigid rules, which its followers believe to be far superior to the original. Not only are they certain that it's the best language in the world, but they're willing to burn those who disagree at the stake.

PHP would be Cafeteria Christianity - Fights with Java for the web market. It draws a few concepts from C and Java, but only those that it really likes. Maybe it's not as coherent as other languages, but at least it leaves you with much more freedom and ostensibly keeps the core idea of the whole thing. Also, the whole concept of "goto hell" was abandoned.

C++ would be Islam - It takes C and not only keeps all its laws, but adds a very complex new set of laws on top of it. It's so versatile that it can be used to be the foundation of anything, from great atrocities to beautiful works of art. Its followers are convinced that it is the ultimate universal language, and may be angered by those who disagree. Also, if you insult it or its founder, you'll probably be threatened with death by more radical followers.

C# would be Mormonism - At first glance, it's the same as Java, but at a closer look you realize that it's controlled by a single corporation (which many Java followers believe to be evil), and that many theological concepts are quite different. You suspect that it'd probably be nice, if only all the followers of Java wouldn't discriminate so much against you for following it.

Lisp would be Zen Buddhism - There is no syntax, there is no centralization of dogma, there are no deities to worship. The entire universe is there at your reach - if only you are enlightened enough to grasp it. Some say that it's not a language at all; others say that it's the only language that makes sense.

Haskell would be Taoism - It is so different from other languages that many people don't understand how can anyone use it to produce anything useful. Its followers believe that it's the true path to wisdom, but that wisdom is beyond the grasp of most mortals.

Erlang would be Hinduism - It's another strange language that doesn't look like it could be used for anything, but unlike most other modern languages, it's built around the concept of multiple simultaneous deities.

Perl would be Voodoo - An incomprehensible series of arcane incantations that involve the blood of goats and permanently corrupt your soul. Often used when your boss requires you to do an urgent task at 21:00 on friday night.

Lua would be Wicca - A pantheistic language that can easily be adapted for different cultures and locations. Its code is very liberal, and allows for the use of techniques that might be described as magical by those used to more traditional languages. It has a strong connection to the moon.

Ruby would be Neo-Paganism - A mixture of different languages and ideas that was beaten together into something that might be identified as a language. Its adherents are growing fast, and although most people look at them suspiciously, they are mostly well-meaning people with no intention of harming anyone.

Python would be Humanism: It's simple, unrestrictive, and all you need to follow it is common sense. Many of the followers claim to feel relieved from all the burden imposed by other languages, and that they have rediscovered the joy of programming. There are some who say that it is a form of pseudo-code.

COBOL would be Ancient Paganism - There was once a time when it ruled over a vast region and was important, but nowadays it's almost dead, for the good of us all. Although many were scarred by the rituals demanded by its deities, there are some who insist on keeping it alive even today.

APL would be Scientology - There are many people who claim to follow it, but you've always suspected that it's a huge and elaborate prank that got out of control.

LOLCODE would be Pastafarianism - An esoteric, Internet-born belief that nobody really takes seriously, despite all the efforts to develop and spread it.

Visual Basic would be Satanism - Except that you don't REALLY need to sell your soul to be a Satanist...

Thanks to jfs and other people on #aegisub for the suggestions. Keep in mind, this list is a joke, and is not meant to offend anyone. Also, if you're a Muslim, please don't kill me. ;)

Note: I wrote a follow-up to this article, regarding the overwhelming reaction that it received.

Read More...

Font hinting and you

... or why you should not use animation on the \fs override tag.

Do you know what font hinting is? If you haven't worked with digital typography you might not, but it's a technique used by (almost) all font rendering systems to make vector fonts (such as True Type, Open Type and Adobe Type 1) appear better on low-resolution mediums like computer monitors. (Actually CRT TV screens are even worse.)

Usually glyphs ("characters") in outline fonts have quite some detail in them, but if you only have 7x13 pixels to render a character in, you're going to have a hard time fitting all that detail in, even if you use sub-pixel rendering such as anti-aliasing and ClearType. That's where font hinting comes it. It's a technique for intelligently modifying the outlines of characters so they look better without completely losing the characteristics that makes the font face special. The basic idea in font hinting is to snap the outlines to the edges of pixels, such that stems and vertical lines take up a whole number of pixels instead of disappearing in quantisation or become a smudge of sub-pixel noise.

So what does that have to do with subtitles? Well, the amount of hinting applied to a glyph depends on the point size of it. The bigger the point size, the less strong the hinting needs to be. For example, here's some text in Verdana at different sizes:

Verdana 8 pixels

Verdana 12 pixels

Verdana 30 pixels

Depending on your font rendering system it might look different (eg. Windows and Macintosh OS X render quite differently) but at least if you're on Windows you should be able to see that the shapes of the letters actually change a bit. The smaller the text size, the more drastic the change.

It's this change of glyph shapes that's interesting in subtitle context. If you've ever needed to have some text change size on screen in ASS subtitles you might have considered whether you should use \t(\fs) or \t(\fscx\fscy). It's the latter that's correct. When you animate the \fs tag you're changing the actual font size requested of the font subsystem, and this also affects the hinting applied to the text.

This leads me to the image at the start of this post: Both of the top two lines with "Test" are rendered in what should have been Arial size 40. But the upper has been given its size with \fs1\fscx4000\fscy4000 while the lower has been given its size with \fs40\fscx100\fscy100. Because VSFilter internally works at 8 times resolution, the upper line is requested as Arial with a font-height of 8 pixels, so it's hinted to look best when rendered just 8 pixels tall, while the other line is requested as 320 pixels tall Arial. The red/blue at the bottom are the same two lines with the border removed, then laid over each other.

Do you now see why you shouldn't animate the font size, but rather the font scale?

Read More...

Aegisub 2.1.6 released

Ooooooooops.

Apparently the fix on 2.1.5 caused audio selection to become much slower. This release will hopefully fix all of those issues. Since this is a very minor change, you can download a RAR with only the new executable (plus its pdb) and extract it over the 2.1.5 install (typically "C:\Program Files\Aegisub"). The RAR "patch" is available here. [Exias' mirror]

If you want to download the complete 2.1.6 installer, you can download it here. [Exias' mirror]

Also, a cookie to the first one who can tell me what Hollywood movie is related to this particular version number. ;)

Read More...

Mac progress...?

We get asked "what about the mac version?" once in a while and yes, it's the eternal problem.

Aegisub can build on Mac and it can run, but unfortunately it's quite hard to make it useful, not to mention the numerous GUI bugs and glitches.

Tonight I managed to make my first running build of Aegisub for PPC (G4/G5) architecture which was (of course) the first thing people started screaming for when I put out my first Intel builds some time last year!

So far this build is essentially useless! It can't load video, can't load audio, has no Automation support, the libass build can't render anything (because Fontconfig is misconfigured) and even the PCM WAV audio provider that otherwise always works, won't. (The PCM WAV problem is due to endianness.)

If you really want to try it anyway, here's a download link: aegisub-mac-r2486-stripped.zip.

Remember: You have no right to complain about this build. I know it's horrible and useless and I'll try to make something better. This is just a proof of concept, it is (still) possible to get Aegisub on Mac and PPC.

Also, while it does run on Intel machines, it's quite slow, especially during startup, as it's not a Universal binary but a PPC-only one. Of course it's also possible to make an Intel version and it shouldn't be a major problem to lipo them together, I just haven't bothered to try yet.

There's no ETA for the next useful version. (But oh, by the way, I have added a new script to the SVN repository. It's called make-app-bundle.sh and can create Application bundles. Quite useful if you're building for Mac yourself! Yes I used it for this build.)

Read More...

Aegisub 2.1.5 released

Due to a fairly serious bug introduced in 2.1.4, here's 2.1.5. Everyone is advised to update to it.

• Fixed a bug in audio display that caused it not to update properly (introduced on 2.1.4)
• Fixed a bug that caused Aegisub to crash if you attempted to load any ASS subtitles with malformed embedded fonts
• Tweaked the layout of the visual typesetting bar

The win32 binary is available here.

BTW, a good way to keep up with Aegisub updates it to subscribe to the Atom feed - I recommend Google Reader.

Read More...

Aegisub 2.1.4 Released

Version 2.1.4 is now out for Windows. The highlights are:

• Hopefully removed the dependency on Visual C++ 2005 SP1 runtimes
• Greatly improved the draw speed of audio display (should make committing on spectrum mode much faster, depending on your settings) - please let me know if any instabilities are caused by this
• Fixed the aspect ratio of video when the audio display is too tall
  
• Added Hungarian translation
• Fixed a styling glitch in the fonts collector and translation assistant
• Made Aegisub capable of running if ffms2.dll isn't found

It can be downloaded HERE.

Read More...

Three things that Java could learn from C++

This is a mostly off-topic rant that is being posted because I know that a good portion of our user base is composed of programmers.

Ever since I started working with Java, a few months ago, there have been many things that I have felt SHOULD be there, but aren't. Three, in particular, have always bothered me: stack building, operator overloading, and const-correctness. For the rest of this post, I will write snippets in both C++ and in Java to illustrate the differences.


1. Stack building
Creating objects on the heap is slow. Not only does it involve complex algorithms for determining WHERE to allocate the memory, but it also means that you're giving more work for the garbage collector when you're done with the object. In many situations, you will have to allocate many small temporary objects and then never use them again. Stack building makes this much faster, not to mention EASIER. Since Java lacks this feature, you are forced to use annoying workarounds (such as keeping pools of objects) if performance becomes critical.

C++:

bool isNormalPointingAt(Vector3f a,Vector3f b, Vector3f dir) {
    return (a.cross(b).dot(dir) > 0);
}

Java:

boolean isNormalPointingAt(Vector3f a,Vector3f b, Vector3f dir) {
    Vector3f normal = new Vector3f();
    normal.cross(a,b);
    return (normal.dot(dir) > 0);
}

In the above C++ example, the result of a.cross(b) is stored in a temporary variable in the stack, which is then dot()ed with dir. This could be done in Java if every such method allocated a new instance, but that would quickly become prohibitively slow.


2. Operator Overloading
This is a hotly debated topic. Many people insist that operator overloading can lead to unreadable code, if you start overloading operators to perform things that are illogical - but the same is true for method names, you can have an "add()" method that performs a multiplication. However, especially when working with mathematical vectors, operator overloading makes your code way easier to understand. Bellow is a method that, given 4 control points and a "t" parameter in the range [0,1], finds the corresponding point along a cubic Bézier curve:

C++:

Vector3f getBezierCubicPoint(Vector3f a, Vector3f b,
        Vector3f c, Vector3f d, float t) {
    float u = 1-t;
    return (u*u*u)*a + (u*u*t)*b + (u*t*t)*c + (t*t*t)*d;
}

Java:

Vector3f getBezierCubicPoint(Vector3f a, Vector3f b,
        Vector3f c, Vector3f d, float t) {
    float u = 1-t;
    Vector3f result = new Vector3f();
    Vector3f tmp = new Vector3f();
    tmp.scale(u*u*u, a);
    result.add(tmp);
    tmp.scale(u*u*t, b);
    result.add(tmp);
    tmp.scale(u*t*t, c);
    result.add(tmp);
    tmp.scale(t*t*t, d);
    result.add(tmp);
    return result;
}

<sarcasm>Yeah, operator overloading really made that code a lot harder to read...</sarcasm> Operator overloading is a tool. It can be very useful, as the example above demonstrates. I don't think that the language designers should remove that power from their users just because some won't know how to use it wisely.


3. Const-correctness
This one is possibly even more infuriating than the above two points, because it makes proper encapsulation of data much more complicated (not to mention slower). Consider this class in C++ and Java:


C++:

class Body {
public:
    const Vector3f& getPosition() const {
        return position;
    }
    void setPosition(const Vector3f& pos) {
        position = pos;
    }

private:
    Vector3f position;
};

Java:

public class Body {
    public Vector3f getPosition() {
        return position;
    }
    public void setPosition(Vector3f pos) {
        position = pos;
    }
    private Vector3f position = new Vector3f();
}

What's wrong with the above example? Here, let me illustrate it with some code:

C++:

Body body;
body.getPosition().x = 5.0f; // compile error

Java:

Body body = new Body();
body.getPosition().x = 5.0f; // works

Basically, Java allows you to modify an object's private member without using its "set" method! There is no way to declare that a given object is "read-only" (final only means that the reference can't be reassigned), so you can't prevent that code from working. If you really must be sure that position can't be modified like that, then you have to change your Java class to this:

Java:

public class Body {
    public Vector3f getPosition() {
        return (Vector3f)position.clone();
    }
    public void setPosition(Vector3f pos) {
        position = (Vector3f)pos.clone();
    }
    private Vector3f position = new Vector3f();
}

In other words, you're now returning a full copy of the object. There are two major problems with this: First, the previous code STILL COMPILES. Since the user will have no way to tell if he's getting the actual position or a copy of it (unless he enters the original source or look in the documentation), he might try to modify the position that he got, and then be surprised that it doesn't work. The second problem is that returning an entire copy might be SLOW. What if, instead of a vector, it was an image? And what if it was accessed many times per second? This could quickly become impossibly slow. Java offers no solution for this problem.

(In case you're wondering, I also had to add a clone() to the set method, because otherwise the caller might call the set method, but keep the reference that it passed to it and modify it later.)


Conclusion
While many programs don't suffer from those problems much, there are certain applications that become a true nightmare to write and maintain - physics simulations or anything to do with vectorial math are the obvious example (that's why I kept using "Vector3f" classes above). If Java is supposed to be a cleaner and easier version of C++, then why is it that writing that sort of code in Java is much harder and much less robust?

I am aware that C# supports some (all?) of the above, but it doesn't as yet have as much portability as Java does. Indeed, it seems that C# is what Java SHOULD HAVE BEEN. If Sun doesn't start fixing this sort of thing in Java, then Microsoft just might take the lead. Meanwhile, I'll have to stick to writing that kind of abomination in Java. To think that it's much easier to code this sort of thing in
C++...

Read More...

Bug tracker lost...

Oops.

We lost the bug tracker, and the latest back-up of it is from 2008-09-17. The chances to restore any newer dataset are very slim.

The server the tracker was hosted on has been shut down, and we don't have a replacement yet. We're trying to find a solution for the hosting.

Until later notice, expect bugs.aegisub.net to time out.

Read More...

Aegisub 2.1.3a Released

Yes, it took a while, but here's a new release preview build. The biggest changes from 2.1.2 are:

• FFmpegSource2 is the new default audio and video provider, replacing Avisynth. This should provide frame-exact seeking (with keyframe support) on AVI, MKV and MP4 files, as well as other benefits. This is still a bit experimental, however. If you have any issues, just switch back to Avisynth in options.
• The DirectSound audio player was reverted to what it was in 2.1.1, since 2.1.2 seems to have critical issues related to it. [Edit: jfs says that the issue was after 2.1.2]
• Many small issues around the program were fixed.
• VSFilter has been updated to the MPC-HC 2.39 version, which includes jfs's new patches (see this post)
  
• Aegisub is now built against Visual C++ 2008 SP1 runtimes. Hopefully there will be no issues related to this (ASSDraw is still built against 2005 SP1 runtimes, due to library issues). If you can't run Aegisub, try installing this and reporting how it goes.
  

A listing of other fixes can be found on TheFluff's builds page. This release includes the Brazilian Portuguese (100%), Catalan (99%) and Spanish (99%) translations. All other translations are too outdated, and were left out. If you are willing to update any of them, please let us know.

The download link to the installer is: http://www.malakith.net/amz/aegisub/aegisub-r2429a-setup.exe

As usual, feature requests and bug reports go in the bug tracker. Please leave your feedback!

Note: previous (non-a) release got nuked due to lack of Freetype2 support, which would cripple Fonts Collector.

Read More...

Two Firefox extensions that you'll want

If you do any sort of Japanese reading on the Internet, you'll want these two Firefox extensions:

XHTML Ruby Support
Furigana Injector

The first one adds proper ruby (a.k.a. furigana, in the case of Japanese) support to Firefox. The second one is more interesting: it adds furigana to kanji on websites that don't have it, making it much easier to read Japanese text.

An interesting side-effect of having proper ruby support in Firefox is that the times in blogger look quite odd, with the full date above them.

Read More...