|
|
combo-doc-bad.png (177,600 bytes) |
|
|
Fixed, please test. I see you don't use TurboPowerIProDsgn package which gives a nice HTML rendering for code help in editor hints and in OI Infobox. Without it the text looks butt-ugly. |
|
|
Still not nice: too less endOfLines here: we need 5 styles of Combobox as 5 new lines. picture shows. |
|
|
infobox.png (72,209 bytes) |
|
|
The formatting is totally screwed without HTML rendering. Fortunately TurboPowerIProDsgn works on every platform and it is installed by default. It is now the "standard" way to look at code help. Does it work well for you? After my fix all list items from the original XML file are included, aren't they? If you want to improve text rendering without HTML, please look at function HTMLToCaption() in unit IDEHelpManager. It only strips the tags out and copies the text without any formatting. For most people this is a low priority issue because HTML rendering works well. If you plan to provide a patch then I can keep this issue open for a while. Otherwise it closes soon. The task is not trivial. The code must do partly the same things that a HTML parser + renderer already does. |
|
|
Another idea: there must be some "HTML to plain text" rendering engines out there. If you find one with a proper license we could integrate it. It cannot show graphs or different font sizes but it could render text as nicely as possible. Such code should not be very big. We don't want to bloat Lazarus with code that is almost never used. Remember, most people use the HTML rendering by provided by TurboPowerIProDsgn. [Edit] After thinking a little I realized that even the HTMLToCaption() function could be improved easily without implementing any state machine. Spaces could be removed after "p" tag, list items would force a newline etc... |
|
|
fixed1.png (73,335 bytes) |
|
|
fix-html.diff (576 bytes) |
|
|
Tks for note about HTMLToCaption. Added fix for LI tag. And picture shows result |
|
|
Actually HTMLToCaption() did more layouting than I remembered but it didn't work very well with lots of whitespace. I ended up making a proper parser / renderer after all in r55319. It is a general purpose class, not specific to the IDE help system, so I placed it in LazUtils package. Now I feel I wasted a lot of time. Something in parsers is pulling me. Damn! The parser is robust and can be easily extended. For example the attribute in <div class="title"> could be parsed and used. Please test. How does it work? |
|
|
You did not small work. good... Good is to use "const" param in Render(), AddOutput(); name param as "aStream" |
|
|
Wish: add property LineEnding (with default of OS LineEnding), to use #_10. |
|
|
Maybe it is slower, but good: delete HtmlEntity() and use simple post handling s:=StringReplace(s, '....', '<', [rfReplaceAll]); |
|
|
Why would StringReplace be good? It would be MUCH slower, you are right about that. Did you notice my renderer does not copy the same big memory areas many times, it copies char by char only once what is needed? LineEnding (with some other name) could be a useful property for somebody although not needed for the current use case. |
|
|
Parser works ok for me, for k OI properties result is good. |
|
|
Just to consider: Extracting text from html would be a simple exercise for the fasthtmlparser unit html2text; {$mode objfpc}{$H+} interface uses Classes, SysUtils; function ExtractTextFromHTML(const AHTMLText: String): String; implementation uses fasthtmlparser; type THTMLTextExtractor = class private FParser: THTMLParser; FText: String; protected procedure FoundTextHandler(AText: String); public constructor Create(AHTMLText: String); destructor Destroy; override; function Execute: String; end; constructor THTMLTextExtractor.Create(AHTMLText: String); begin FParser := THTMLParser.Create(AHTMLText); FParser.OnFoundText := @FoundTextHandler; end; destructor THTMLTextExtractor.Destroy; begin FParser.Free; inherited; end; function THTMLTextExtractor.Execute: String; begin FText := ''; FParser.Exec; Result := FText; end; procedure THTMLTextExtractor.FoundTextHandler(AText: String); begin if AText = '' then exit; // Remove multiple line breaks from text start if (AText[1] in [0000010, 0000013]) then begin while (AText <> '') and (AText[1] in [0000010, 0000013]) do Delete(AText, 1, 1); AText := LineEnding + AText; if AText = '' then exit; end; // ... and from text end if (AText[Length(AText)] in [0000010, 0000013]) then begin while (AText <> '') and (AText[Length(AText)] in [0000010, 0000013]) do Delete(AText, Length(AText), 1); AText := AText + LineEnding; if AText = '' then exit; end; FText := FText + AText; end; function ExtractTextFromHTML(const AHTMLText: String): String; var extractor: THTMLTextExtractor; begin extractor := THTMLTextExtractor.Create(AHTMLText); try Result := extractor.Execute; finally extractor.Free; end; end; end. |
|
|
+ 'A': // Link + Result:=AddOutput(' 👀'); + '/A': + Result:=AddOutput('👀 '); eye chars?? Must be a property and better '[]' chars, IMO |
|
|
Result:=AddOutput('🔹'); And prop for this char, pls. |
|
|
+ Result:=AddOutput('&'); // Entity not found, add just '&'. Need prop, and better "?" char. |
|
|
I removed the eyes and added a TitleMark property in r55329. Unicode Emojis give nice opportunities for layout. They are essentially graphics inside text. IMO '🔹' looks good with a title. '&' without entity is not legal HTML, but if one is encountered then it must be copied verbatim. Why would you change it to '?' If input is '&xxx', output must also be '&xxx' and not '?xxx'. @wp: Yes, I believe fasthtmlparser and SAX could be used. However the code does not only extract text from HTML, it also renders in within the confines of pure text output. To my surprise I did not find such code. My class is loosely based on the original HTMLToCaption() function by Mattias. The function copied large memory blocks repeatedly while removing tags and thus was slow with big HTML. I was kind of carried away when making an optimized class. BTW, your example code removes newlines but it should remove the excess spaces, too. Delete(AText, 1, 1) inside a big loop is butt-slow. :) I am resolving this issue. The code can be discussed on mailing list or forum. Patches can be added. |
|
|
rendr.diff (3,282 bytes) |
|
|
Made refac, 6 new properties, patch added. |
|
|
Applied, although I don't find some of the properties very useful. For example who would want to change the '...' at the end of truncated output? I renamed one propery as IndentStep. |
|
|
@Juha there is Unicode char for "3 dots". |
- Anonymous
