No updates since a long time

[GoogleCodeExporter]

Is anybody working on gdipp project or the developers left this project for 
good ?

I don't see any updates since Sep 2010.

Is anybody out there who is looking into the issues and trying to fix them ?

Original issue reported on code.google.com by mallik.a...@gmail.com on 17 Jan 2012 at 4:35

[GoogleCodeExporter]

Well, basically I spent all my free time to update the code, preparing for its 
formal debut of version 1.0. Sorry for not solving old issues. You can check 
the code progress at http://code.google.com/p/gdipp/source/list if you interest.

Original comment by crendk...@gmail.com on 17 Jan 2012 at 7:57

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

Thank you for your continued work on gdipp crendking.

Original comment by jmbat...@gmail.com on 18 Jan 2012 at 12:24

[GoogleCodeExporter]

Thank you for your support crendking. I really appreciate. I could see some 
fixes on the code progress page. Why don't you release a bete version of those 
fixes. When can we expect the next release of the software.
Once again thank you for your time and effort.

Original comment by mallik.a...@gmail.com on 18 Jan 2012 at 4:25

[GoogleCodeExporter]

Because it is not really for a beta release. I personally tend to make things 
good and complete. Therefore for me, beta version is general like RC version. 
However, I do have some internal alpha testers. Some of them are really 
helpful. Thanks to them.

Many people email me about the progress in the past year. I replied almost 
every one of them. Below is an latest email that I sent to an user. You can 
read it.

  "Actually the new version has been tested by myself for several days, and the rendering components work stably. However, it is still not qualified for a release. First, because the new version (1.0) is featured server/client mode, it is critical to ensure the API are working and stable as well. This part is pretty time-consuming. Second, before public release, there will be a internal alpha test. This will also take some time. Third, I'm planning to release the new 1.0 version with new project new, a formal name, as well as accompanying documentation. The renaming is done, but the documentation needs a lot of work. Therefore, I cannot guarantee a near publish.

  So far gdipp is done all by myself. All the work have to be done in my off-work time. It is good that I have complete control over the progress of it, but in expense of slow progress. Please be patient. Thanks."

Original comment by crendk...@gmail.com on 18 Jan 2012 at 5:08

[GoogleCodeExporter]

Thanks for the update!

Original comment by jmbat...@gmail.com on 18 Jan 2012 at 8:28

[GoogleCodeExporter]

Yes crendking thanks for the update. We are all looking forward to version 1.0. 
 However there is also another semi-alternative that has cropped up lately: the 
ttfautohint project (http://www.freetype.org/ttfautohint/).  It changes TTF 
fonts (I don't think it does OTF though) embedded hints to use 
FreeType-generated hints which are usually much better.  Using it you can 
replace all your Windows fonts with modified TTFs that work with both GDI and 
DirectWrite programs.  I have used it on two XP machines and it is pretty good 
(haven't done it on my gdipp-using Win7 machine because I use gdipp there).

Original comment by greatq...@gmail.com on 18 Jan 2012 at 2:05

[GoogleCodeExporter]

Thanks for the update. Can't wait to see the version 1.0

Original comment by mallik.a...@gmail.com on 18 Jan 2012 at 5:46

[GoogleCodeExporter]

To greatquux, the ttfautohint project is definitely interesting (I think it is 
part of the FreeType project). However, according to its description, the hint 
table of the font is permanently replaced. The FreeType Auto-Hinting 
documentation (http://www.freetype.org/autohinting/) has not been updated for 
some time. I'm not sure if it is stable enough to apply system-wide and 
irreversibly. 

In contrast, gdipp also generates FreeType auto-hinted glyphs when you specify 
the "auto_hinting" setting to be 1, on the fly. Therefore, gdipp provide user 
safer and more flexible options to choose. For example, I personally likes 
FreeType auto-hinting to be used on all fonts, except Tahoma. I can just write 
a separate setting for "Tahoma.*" with <auto_hinting>0</auto_hinting>.

About DirectWrite, DirectWrite controls the way of how to load glyph outlines. 
So far I have not found an approach to interfere with it. The deepest I can 
interfere is the rasterization stage. If you cares the hinting effect of 
DirectWrite applications (such as Firefox), maybe ttfautohint is the only 
choice.

Original comment by crendk...@gmail.com on 18 Jan 2012 at 8:51

[GoogleCodeExporter]

@crendking - yes, ttfautohint modifies the font files directly, so I do keep a 
backup copy of all the fonts in a different directory. You could just choose 
not to replace the Tahoma font with an autohinted version, but I haven't 
replaced gdipp and don't plan to either (it has much more control and options). 
 Although it would be nice if gdipp was able to hook into DirectWrite-using 
applications I think most people would be happy as long as it keeps working 
with Google Chrome. :)  

Original comment by greatq...@gmail.com on 20 Jan 2012 at 1:41

[GoogleCodeExporter]

I have been long time not playing with Chrome DLL injection. Many people know 
Chrome is tightly secured. I provided a way to inject DLL in version 0.5.0. It 
seems the mechanism is not working in the current Chrome versions.

As I replied before, since Chrome intentionally rejects any kind of hooking and 
injection, it is against its well to do it forcefully. I can spend some time 
trying if standard NPAPI would work (tried before and failed because it cannot 
load external files), but only with lower priority.

Original comment by crendk...@gmail.com on 20 Jan 2012 at 10:03

[GoogleCodeExporter]

Google Chrome works better with --disable-sandbox but the current injection 
mechanism is working for me w/ Chrome 16 and Win7 x64 SP1.  It works in 
development versions too, there is a problem with bold text however when the 
CSS shadow is used.  I have had luck using a style script to turn off the CSS 
shadows/

Original comment by greatq...@gmail.com on 23 Jan 2012 at 8:12

[GoogleCodeExporter]

@greatq...@gmail.com
How to turn off CSS shadows in Google Chrome ?
Could you please let me know about the style script you are talking about and 
how to use it ?

Original comment by mallik.a...@gmail.com on 3 Feb 2012 at 8:28

[GoogleCodeExporter]

The style script that disables CSS shadows in Chrome can be found in the bug 
report for #182 - 
http://userstyles.org/styles/19166/firefox-3-5-no-text-shadow-on-websites (use 
the Stylish extension for Chrome).

Original comment by greatq...@gmail.com on 6 Feb 2012 at 1:13

[GoogleCodeExporter]

@greatq...@gmail.com
I used the style script found in the bug report for #182.
But it doesn't work for me.
I am using Chrome 18.

Original comment by mallik.a...@gmail.com on 6 Feb 2012 at 1:19

[GoogleCodeExporter]

Hmm.. that is weird because I could swear everyone had determined that CSS text 
shadows were the problem.  But I just brought up 
http://reference.sitepoint.com/css/text-shadow/demo and the shadows look fine 
with gdipp. Of course I am using Chrome 17 (just promoted to stable today) - 
it's quite possible Chrome 18 has changed the text rendering again to a way 
that screws up gdipp and we just have to wait for a fix.

Original comment by greatq...@gmail.com on 9 Feb 2012 at 1:34