Synopse Open Source

For our PDF generation Open-Source library, this is a small fix update.

It can now be compiled under Delphi XE2.
But it's still working from all previous IDE versions, starting with Delphi 5, and still 100% free - released under GPL/LGPL/MPL license, choice is yours.

Everybody is buzzing about FireMonkey...

Our little mORMot will like FireMonkey!
Here is why...

For our ORM framework, we implemented an efficient SQLite3 wrapper, joining statically (i.e. without any external dll) the SQLite3 engine to the executable. SQLite3 is in fact used as the DB kernel of the framework. For instance, thanks to its unique virtual table mechanism, even tables in other databases (like Oracle or MSSQL) are available as if they were SQLite3 tables.

We just made this wrapper independent from our ORM, in a new dedicated unit, named SynSQLite3.pas.

It was an easy task to let this unit be called from our SynDB database abstract classes.

That's it, our SynOleDB unit seems alive and running well.

OLE DB (Object Linking and Embedding, Database, sometimes written as OLEDB or OLE-DB) is an API designed by Microsoft for accessing data from a variety of sources in a uniform manner. It was designed as a higher-level replacement for, and successor to, ODBC, extending its feature set to support a wider variety of non-relational databases, such as object databases and spreadsheets that do not necessarily implement SQL.

SynOleDB unit implementation has been made with several points in mind:

• Tested with SQL Server 2008 R2 and Oracle 11g providers from Microsoft and Oracle; 
• Ability to be truly Unicode, even with pre-Unicode version of Delphi (like Delphi 7 or 2007); 
• Could access any local or remote Database, from any version of Delphi, since it doesn't use the DB.pas unit or any related part of the VCL (even the Delphi 7 personal or the Turbo Explorer editions), just for free; 
• Handle NULL or BLOB content for parameters and results; 
• Avoid most memory copy or unnecessary allocation: we tried to access the data directly from the retrieved data buffer, just as given from OleDB; 
• Was therefore designed to achieve the best performance possible: most time is spent in OleDB: the code layer added to the OleDB customer is very thin; 
• True OOP architecture, to be used with any OleDB provider (allowing custom parameters or such), and even without OleDB (in the future, direct access to any DB client could be used); 
• Could be safely used in a multi-threaded application/server (with one TOleDBConnection per thread); 
• Allow parameter bindings of requests, with fast access to any parameter or column name (thanks to TDynArrayHashed);
• Late binding of column values in Delphi code;
• Direct JSON content creation, with no temporary data copy nor allocation; 
• Designed to be used with our mORMot ORM, but could be used stand-alone (a full Delphi 7 client executable is just about 200 KB), or even in any existing Delphi application, thanks to a TQuery-like wrapper.

When it deals with parsing some (textual) content, two directions are usually envisaged. In the XML world, you have usually to make a choice between:
- A DOM parser, which creates an in-memory tree structure of objects mapping the XML nodes;
- A SAX parser, which reads the XML content, then call pre-defined events for each XML content element.

In fact, DOM parsers use internally a SAX parser to read the XML content. Therefore, with the overhead of object creation and their property initialization, DOM parsers are typically three to five times slower than SAX. But, DOM parsers are much more powerful for handling the data: as soon as it's mapped in native objects, code can access with no time to any given node, whereas a SAX-based access will have to read again the whole XML content.

Most JSON parser available in Delphi use a DOM-like approach. For instance, the DBXJSON unit included since Delphi 2010 or the SuperObject or DWS libraries create a class instance mapping each JSON node.

In a JSON-based Client-Server ORM like ours, profiling shows that a lot of time is spent in JSON parsing, on both Client and Server side. Therefore, we tried to optimize this part of the library.

A task dialog is a dialog box that can be used to display information and receive simple input from the user. Like a message box, it is formatted by the operating system according to parameters you set. However, a task dialog has many more features than a message box.

Windows provides a generic task dialog available since Vista/Seven. But there is none available with previous versions of Windows, i.e. Windows XP or 2K.

This unit (licensed under a MPL/GPL/LGPL tri-license) will use the new TaskDialog API under Vista/Seven, and emulate it with pure Delphi code and standard themed VCL components under XP or 2K. It will compile from Delphi 6 up to XE, and is Unicode ready.

There will be an upcoming 64 bits Delphi compiler. Embarcadero promised it.

Here are some points on how you could make your code ready to compile under FPC 64 bits, therefore (I hope) under future Delphi 64 bits compiler.

The Synopse Big Table library has been updated to the 1.8 version.

Some bug fixes, a Thread safe way of working and a some new methods (AddFile, GetPart).

The Unicode part of the Synopse PDF engine has been updated in order to support right-to-left languages and ligatures (i.e. glyph shaping).

Therefore, our Open Source engine is one of the few PDF producer able to natively handle Arabic languages. Even most commercial engines don't implement this nice feature.

In a very interesting comment, PhiS spoke about the Mac OS X Stack Alignment problem, and the way asm code should be written for the future Cross Platform Delphi compiler. Here are some (hope without any Troll hidden) reflections I went through.