DlangIDE v0.8.0 released
bitwise
bitwise.pvt at gmail.com
Wed Sep 27 15:24:29 UTC 2017
On Wednesday, 27 September 2017 at 13:22:20 UTC, Vadim Lopatin
wrote:
> On Tuesday, 26 September 2017 at 22:35:09 UTC, bitwise wrote:
>> On Tuesday, 26 September 2017 at 15:20:54 UTC, Vadim Lopatin
>> wrote:
>>> New DlangIDE version is released.
>>
>> I've only had time to take a quick look, but this IDE seems
>> pretty good. I was surprised at how fast it loaded up, and how
>> it downloaded the dependencies for the sample project on it's
>> own.
>>
>> The text rendering needs work though. Honestly, I passed this
>> editor up the first time I came across it because of the way
>> the text looks. It reminds me of Visual Studio 2005. I
>> couldn't help but assume the IDE was outdated and probably be
>> abandon-ware.
>>
>> I would definitely change the default font to the platform-IDE
>> defaults:
>>
>> Visual Studio: Consolas
>> XCode: Menlo Regular
>>
>> Also, FreeType has made improvements lately, and now does a
>> much better job of rendering fonts at small sizes(no so
>> blurry). In particular 2.8.1, which just came out, implements
>> a patent-free substitute for MS style clear-type
>> rendering[1][2].
>>
>> [1] http://i.imgur.com/nK8Xu.png
>> [2]
>> https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_LOAD_TARGET_LCD
>>
>> The thick bezels and deep 3D shading make it look retro as
>> well.
>
> For Windows, added libfreetype 2.8.1 dlls.
>
> Made additional fixes for better font rendering.
>
> Win32 binaries are uploaded to
> https://github.com/buggins/dlangide/releases/tag/v0.8.2
>
> To disable freetype, delete libfreetype-6.dll
>
> Consolas/Menlo are already selected if "Default" font is chosen
> for editors.
Hey, thanks!
Looks good.
One small thing though - when you use the LCD/BGR style fonts,
you get a mismatch between the font metrics and bitmap size.
So if you're using FT_LOAD_TARGET_LCD, then some of these may be
true:
glyph.bitmap_left != (glyph.metrics.horiBearingX >> 6);
glyph.bitmap_top != (glyph.metrics.horiBearingY >> 6);
glyph.bitmap.width != (glyph.metrics.width >> 6);
glyph.bitmap.rows != (glyph.metrics.height >> 6);
The result could be a crash, clipping, or misalignment of glyphs,
depending on the assumptions made by your blitting code.
I asked about this on the FT mailing list, and unfortunately,
they don't believe that the 1 or 2 pixels of padding added to the
bitmap to accommodate the LCD rendering belongs in metrics.
The fix is simply using bitmap_left, bitmap_top, bitmap.width,
bitmap.height, instead of the metrics.
I was looking at the commits and saw that you added kerning, so
was wondering if you hit this problem.
More information about the Digitalmars-d-announce
mailing list