|
|
Home » Developing U++ » Documentation » Documentation how-to...
|
|
|
|
|
|
|
|
|
|
|
|
Re: Documentation how-to... [message #18295 is a reply to message #18294] |
Sun, 21 September 2008 10:07   |
cbpporter
Messages: 1427 Registered: September 2007
|
Ultimate Contributor |
|
|
I guess we can consider it final. Any change at this moment will be IMO a minor one and current is pretty enough and also readable.
I haven't inserted everything at once because I just needed to reinsert some items because of style change, without loosing all the other inserted text. Anyway, that dialog should remember it's context.
One more thing: I think we should have a button that when clicked searches the current selection for paragraphs with code labels and reinserts them, to cope with future style changes. Not a big thing.
I haven't finished math until doc yet because I was waiting for the browser, but I'll finish it now even if the browser is not perfect and commit it.
Also, I would like to help by formating some existing documented pages, because most of them are not labeled. Once we have all the current doc reformatted and labeled, plus at least my 4 doc pages and the sql doc pages and the code browser with doc support, I think we should consider a dev release. Together with the parser enhancements I could make quite an attractive package.
And starting with Monday, my coding "interdiction" is finished, so I can get back to coding as usual . Can I create a branch or something for i18n issues? There quite some work needed which is wchar size agnostic, so you don't have to decide what to do with it yet.
|
|
|
|
Re: Documentation how-to... [message #18297 is a reply to message #18296] |
Sun, 21 September 2008 11:38   |
cbpporter
Messages: 1427 Registered: September 2007
|
Ultimate Contributor |
|
|
luzr wrote on Sun, 21 September 2008 11:51 |
I am working on automated "repair tool".
|
Great! Anyway, SVN is down, so I have to wait with docs.
Quote: |
Well, I can create it... Though I doubt about "wchar agnosticity" 
|
It is wchar agnostic in the sense that I want to write the low level renderer first, which on Win32 at least will operate on 16 bits. Even if wchar is 32 bits, for rendering purposes, the latest when WinAPI is called, it will have to be converted to 16 bits, right? We need a not to complicated text renderer, because WinAPI can't really handle mixed font rendering in CJK context at least. I haven't benchmarked it yet, but performance should be equal to previous performance plus the cost of a traverse over the text that must be displayed, so I hope it will be OK. If it is not, I'll need to think of a way to keep the old text rendering, and activate the new one only if the application must be able to display full CJK.
I also started studying some shape recognition, to be able to trace CJK characters and render them manually, for systems that will never be able to have all the fonts installed, but I'm not sure about legal issues here. The traced characters will have their own style, which is distinct form all available styles in a manner that "Arial" font is distinct from "Dotum" font, so it will look very similar on first sight, but when examining the weight of curves, it will be quite different, but still, my data will come from an (or more probably a more than one) available fonts, strictly by pixel analysis, and I don't want to breach any copyright clauses.
This approach has some advantages:
1.It is a viable and lightweight fall back when native rendering using (very large) fonts is not available or not desired.
2.The huge number of CJK characters is reduced to some hundreds of composing characters. This way the rendering for most characters will definable in a couple of bytes.
3.It allows easy definition of gaiji (I'm not going to define any, but I'll include a GUI in the future in my application).
4.It allows easy animation of stroke order.
Disadvantages:
1. Uncertain legal issue.
2. Generating the initial data set will probably take days.
3. Professional fonts will probably have better font hinting.
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 25 12:50:07 CEST 2025
Total time taken to generate the page: 0.00736 seconds
|
|
|