Thursday, April 6. 2006
You can download the 1.8.2 version. The user interface has become much more mature:
The areas which have been improved most are related to the text box and text line object. The text styles can be applied directly from the ribbon, by choosing in a gallery of available styles. The same is true for the fonts.
If you need to define your own styles, simply click on the styles tab, then select either the paragraph or the character style sub-tab and copy/modify or create your styles.
I've also added support for WMF/EMF (Windows Metafiles) import. Selecting such an image when drawing an image object will work; internally, the image is converted to a bitmap with the WMF/EMF specified DPI resolution. This can lead to jaggy images when printing.
As always, please let me know if something does not work properly for you. Thanks!
Saturday, March 18. 2006
This is a bug-fix release to address a problem related to the file export. Creative Docs .NET crashed when a new document was opened after the previous one had been exported and closed.
Get version 1.8.1.
Thank you Roman for your bug report. It helped a lot!
Tuesday, March 14. 2006
This release fixes quite a few bugs (and possibly adds a few new ones  ) as we finally added a panel to edit the properties for bullets and numbering.
You can download the 1.8.0 version and give it a try:
You can choose from a list of predefined numbering styles. If none fits your needs, simply pick the one which looks most what you'd like to get and click on the Customize button:
In this example, the first level is numbered as 1., 2., 3., etc. The second level is numbered alphabetically a., b., c., etc. The third level is numbered with roman digits i., ii., iii., etc. In this case, every level has been set to be independent from the previous levels, which will be useful to create multi-level lists (left-hand side of following example).
You could also have defined a numbering applied to titles, in which case every level keeps the numbering of the previous level and appends to it. Clearing the arrow button (bottom left of the panel, titled Override former levels) for every level would produce the right-hand side of this example:
Hint: If you want to create documents with predifined text styles, you should open the settings (F5), switch to the Global settings, General tab, and define a template such as normal.crmod which is installed in the Samples folder usually located in c:\Program Files\Creative Docs .NET.
Thursday, February 23. 2006
After a long month of silence, we have finished the implementation of the text styles. Ready internally since fall 2005, the text style proved a real challenge to make them easy to define and use in the GUI. We wanted both something rich (to benefit from our powerful text engine) yet not too different from what Microsoft Word users expect.
If you try out the 1.7.0 version, you will notice that we have provided you with a few default styles:
The numbered styles cannot be edited (yet) as we are still working on the bullets and numbering pannel. But you can already try them out if you want.

To change the level in a list, use the indentation buttons, found in the ribbon:
Other changes
- Fixed the PDF Export engine. It did not work for cultures where the decimal separator was not a period (e.g. in France, where it is a comma).
- Fixed the undo/redo issues when objects have been exploded.
- Shadows are smoother when exported as bitmaps or PDF.
- The mouse coordinates are displayed properly when a grid is active.
- The text line snaps to the grid if it is active, when it is created by a single click.
- The minibar (the small palette which pops up automagically) won't show up if the mouse has been moved after a click.
Friday, January 13. 2006
I mistakenly generated a full debug release when I prepared the 1.6.0 version. Please use the updated version 1.6.1 instead (it's cleaner). You can download it here. Sorry for the inconvenience.
Thursday, January 12. 2006
We are excited to announce this new release available here, which includes an object which was missing in version 1.5.0, the text line. It is a very flexible object indeed:
Since the text engine is the same for the text line than for the text box, you have access to very rich functionality. The text line is in no way a cripple
Other improvements include: - A simple text find and replace function.
- Easier text box creation. Just click to create a text box with default dimensions.
- Multiple page formats. In the Pages tab, expand the bottom pannel to specify the page dimensions.
- A better conversion algorithm. It is used when an old text document is upgraded to use the new objects.
This version also includes several fixes related to the text flow, the font handling and the undo/redo support.
Sunday, January 8. 2006
I just realised that I did not explain why pre-1.5 versions of Creative Docs .NET used so much memory. The reason is simple: in order to be able to provide information about the fonts installed on the system, the framework loaded all fonts in memory (full font load, not just the name table). This consumes a huge amount of memory... In the 1.5 version, the application builds a font cache (which requires all fonts to be loaded once); it subsequently only needs to load the information from the cache, which is much faster and needs only a few kilobytes for every font.
When the font list changes (a new font is added or an existing font is removed), the application will rebuild the cache. When this happens, a message shows up in the splash screen.
Thursday, January 5. 2006
Karl asked why we used .NET and not standard C++ against the raw Win32 API to write our framework. He moreover observes that a freshly started Creative Docs .NET instance uses 240MB on his machine and takes 30 seconds to launch... That's a lot and reflects typical values for pre 1.5 versions (more on that below).
My own measurements show that version 1.5 has a working set of about 90MB and that .NET heaps account for about 17MB reserved bytes (33MB reserved).
But back to the original question: why .NET and not just C++/Win32 for the framework?
More than 10 years ago I started working on a portable GUI toolkit (visit OPaC historic web site), which only required very minimal support from the underlying operating system. All the drawing was done internally using a home-made 2D graphics engine, with alpha transparency support. The memory was tracked by a custom garbage collector, which relied on C++ wrapped pointers and reference counting; it was also able to properly handle cycles in complex graphs and I was very proud of it. Serialization and deserialization of object instances was automatic and did not require explicit support.
This was all nice and fun, but tedious to implement and maintain. There were tons of macros which provided something similar to runtime introspection (what .NET calls reflection) to support all the framework magic. The project went through several major changes in order to keep up with my ideas of improvements.
But then, Microsoft announced the .NET platform.
I was stunned: they had just developed the whole infrastructure and language (CLR and C#) which I was trying to painfully build in pure C++. It was both a dream coming true and an uncredible nightmare: I could either switch to .NET and benefit from the huge work done by Microsoft or continue to work with my own C++ code, and stay back from the big move.
I did some quick performance tests and was very surprised to discover that .NET was in most areas about as fast as what I had implemented in OPaC, or even faster, so the choice finally proved easy (yet, trashing a few hundred thousand lines of code remained painful).
Switching to .NET was a sensible choice. I lost some control on the low level code, but this is far outweighted by the advantages offered by the CLR/C# duo. The working set has increased (the number of DLLs required to run even a very simple .NET application is high) but this should not be dramatical as memory prices continue to fall. What's 100MB of RAM today, anyway?
For those who are interested in seeing what kind of application could be achieved with the old OPaC framework (on Win32), download an ancestor of Creative Docs .NET, named PAGE, here. It works only on 16bpp displays, so be sure to configure your display to 65,536 colors before launching it...
Saturday, December 24. 2005
We are glad to announce the release of version 1.5.0. It is the first non-beta release since we replaced the text engine in Creative Docs .NET. Download version 1.5.0 here and please report problems by placing a comment in this blog or send a message to bugs [at] creativedocs.net.
There are a few improvements over 1.4.9, most notably: - It is possible to convert a text object to curves by right.clicking with the Select tool:

- The undo/redo history contains more meaningful descriptions for the actions done while editing the text:

- Bug fixes. There are no known bugs (but the text object is too slow to create even medium-sized documents).
Wednesday, December 21. 2005
We are still working on the Christmas release (which will be tagged 1.5.0) but we felt that the current internal version 1.4.9 was stable enough to be released as a new BETA version. Download version 1.4.9 here and please report problems by placing a comment in this blog or send mail to bugs [at] creativedocs.net.
Here are a few highlights for this release:
- New shaper tool, which can be used to modifiy the shape of a polyline or Bézier curve. Simply drag a curve to change its shape, or move a secondary point of a curve and hold down CTRL key to see smart constraints:

- The ribbon has been much improved. It contains all commands organised in logically grouped tags and provides immediate access to the preferred commands in a small toolbar, the Quick Commands Toolbar:

- A minibar pops up with (hopefully) the most useful commands in a given context. Here is what it looks like:
 The commands shown in a minibar are tool-related. In left example, the selection tool was active, whereas in the other examples, the shaper tool was used.
- The text object has been rewritten from scratch. Explore it: the commands to change most day-to-day properties are in the ribbon; the pannels on the right give access to the detailed properties.
The text has also an associted minibar which is displayed when the mouse button is released after a selection:

Warning: in this version, you can no longer edit texts created in the previous releases. This is a breaking change!
Wednesday, December 14. 2005
November and December have been very busy months. Daniel and I are working very hard in order to release a new version of Creative Docs .NET before Christmas... 2005. Our main goal is to ship a stable, even if not fully finished, new text object (known as Text II), since the one implemented in version 1.1 was really lame.
The new text object supports following properties:
- Font face and style, bold and italic inversions, absolute and relative font size, font glue, font color, kerning, ligatures, special glyphs, glyph substitutions, numerous spaces, etc.
- Underline, overline, strike out with position, width and color.
- Superscripts and subscripts, with relative size and offset.
- Alignment (left, right, center), justification & hyphenation.
- Leading (fixed or automatic) and grid fitted paragraph or line alignment.
- Spacing (space before paragraph, space after paragraph).
- Keeps (keep at least n lines together, keep with following or preceding paragraph)
- Start paragraph at new frame, new page, odd page, even page.
- Padding (left, right, indentation level).
- Rich tabs (left, right, centered, decimal point, etc.).
- Language (hyphenation only available in French for now).
However, you'll have to wait until 2006 to get your hands on text styles, bullets and numbered lists. Because of time constraints, we decided against trying to finish the user interface related to these features. But most of the low level code is already in place now; e.g. styles are used internally to represent local settings.
Thursday, November 17. 2005
A few days ago, Paint.net reached 1 million downloads. That's properly amazing! I wonder how long it will take for Creative Docs .NET to reach this kind of exposure.
So please, keep downloading it
Tuesday, November 1. 2005
Here is a demo of what can be done when using the Bickham Script Pro font in the experimental text object:

This font defines tons of typographic alternates for the glyphs. The lower case letter "f", for instance, has 8 different shapes. Applications such as Adobe InDesign are smart enough to select automatically the proper alternate, based on information found in the GSUB table.
Sunday, October 30. 2005
In the Common.Text project ( Text II, part 1), the text is stored internally as 64-bit character codes ( ulong in C#). At first, using 64 bits to store a single character may seem foolish, as most western languages would be perfectly happy with an 8-bit encoding. Since .NET uses 16-bit character codes to represent Unicode text, 16-bit ( char) should have been the logical choice for an internationally oriented piece of software.
However, 16 bits are not enough to cover the full Unicode range without using surrogate pairs for the codes above U+FFFF. In UTF-16, these codes are represented using a high-surrogate code (in the range U+D800 to U+DBFF) and a low-surrogate code (in the range U+DC00 to U+DFFF); together, this pair provides 20 bits of useful information, which is used to map the codes from U+10000 to U+10FFFF. Having to deal with the surrogate pairs is just a pain in the neck, and I wanted to get rid of them in order to have a one-to-one mapping between the cursor position to the character offset. So I chose to use at least 21 bits to store a character code (which currently covers the whole defined Unicode range).
So why not use the next natural size (24 bits or 32 bits)? Simply because I also wanted to attach to every character its complete formatting information, plus some status flags which would allow me to decide very quickly if a piece of text belongs to the active selection, or not. I settled to the following internal representation:
As you can see, the formatting information is stored in three chunks, in the top 7+7+18 bits. Then come 5 bits used as markers (flags), 3 bits used to cache the results of a line break analysis, 3 bits to store Unicode related flags and 21 bits for the full Unicode character code.
The formatting information has been split in three in order to speed up the layout analysis. The style index is used as an index into a table which stores font and font geometry related information. The local settings index and the extra settings index are used as indexes into subtables, which store information such as a glyph replacement code, an image name, a link target, a language or a color.
With this setup, characters which share the same font face, font style and font size also share the same style index. Therefore, when analysing a piece of text with a given style index, the layout engine only needs to look up the formatting information once, even if the characters have different colors.
Wednesday, October 12. 2005
Daniel started the implementation of a new text block object, which will offer a much richer text tool, based on the Common.Text project which I developed this summer. Everything is moving very quickly. In about a week, Daniel has built a first version of the new text object (single frame, limited features), version II.
Common.Text supports advanced typographic features, such as ligatures (standard fi, ff, fl but also what Open Type calls discretionary ligatures), kerning (modifying the distance between character pairs, such as A and W, in order to make them visually better spaced) and glyph variants (replacing one character glyph with another one depending on the context). It also features a complex property system, which associates every character to a set of properties (font, size, leading, margins, kerning, color, underlines, etc.) and cascadable styles.
The text engine knows how to layout text into multiple, possibly not rectangular frames. It operates in several passes.
- A first pass, done directly when the text gets inserted into the internal buffer, flags the positions in the text where there are possible breaks, based on the Unicode line break algorithm and on a language-based hyphenation algorithm (currently, we support only the French hyphenation rules).
- A second pass measures the width of every line and decides which break gives the best result. Currently, this decision is based on a single line, but ideally the badness should be computed on a paragraph or page base, just like what Knuth's TEX algorithm does. This would give better results, since the algorithm is not focused on optimizing one line at a time and thus does not lock on local optima.
- The rendering pass is responsible for the justification. Depending on a line's disposition and justification parameters (both are defined in the 0..1 range), the excess space gets inserted at the end, at the beginning or at both ends of the line, possibly scaling existing spaces and even the glyphs (by a small amount).
In order to improve the performance, the engine caches the possible break positions and associates with each paragraph advanced line break information, which includes the ideal width of every line, its position in the frame, etc. Redrawing a text block can be very fast thanks to this cached information.
|