View Issue Details

IDProjectCategoryView StatusLast Update
0037992PatchesLCLpublic2020-10-31 11:22
ReporterZaher Dirkey Assigned Towp  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Summary0037992: ipHTML: SetHtmlFromStr code page utf8
Description* This patch fixed SetHtmlFromStr to take codepage of string arg as UTF8 (can be changed too).
* And I made default charset as UTF8 too
FDocCharset := 'ISO-8859-1';
TagsNo tags attached.
Fixed in Revisionr64078, 64079, 64080, 64088
LazTarget-
Widgetset
Attached Files

Activities

Zaher Dirkey

2020-10-26 16:59

reporter  

iphtml.pas08.patch (1,211 bytes)   
Index: components/turbopower_ipro/iphtml.pas
===================================================================
--- components/turbopower_ipro/iphtml.pas	(revision 64077)
+++ components/turbopower_ipro/iphtml.pas	(working copy)
@@ -2824,7 +2824,7 @@
     procedure DeselectAll;
     procedure SetHtml(NewHtml : TIpHtml);
     procedure SetHtmlFromFile(const AFileName: String);
-    procedure SetHtmlFromStr(NewHtml : string);
+    procedure SetHtmlFromStr(NewHtml: string; ACodePage: Integer = CP_UTF8);
     procedure SetHtmlFromStream(NewHtml : TStream);
     procedure Stop;
     {$IFDEF Html_Print}
@@ -7840,7 +7840,7 @@
     ListLevel := 0;
     StartPos := CharStream.Position;
     {$IFDEF IP_LAZARUS}
-    FDocCharset := 'ISO-8859-1';
+    FDocCharset := 'UTF-8';
     FHasBOM := false;
     Ch1 := GetChar;
     Ch2 := GetChar;
@@ -16141,11 +16141,11 @@
   end;
 end;
 
-procedure TIpHtmlCustomPanel.SetHtmlFromStr(NewHtml: string);
+procedure TIpHtmlCustomPanel.SetHtmlFromStr(NewHtml: string; ACodePage: Integer);
 var
   strm: TStringStream;
 begin
-  strm:= TStringStream.Create(NewHtml);
+  strm:= TStringStream.Create(NewHtml, ACodePage);
   try
     SetHtmlFromStream(strm);
   finally
iphtml.pas08.patch (1,211 bytes)   

Zaher Dirkey

2020-10-26 17:01

reporter   ~0126571

now FDocCharset := 'UTF-8';

Juha Manninen

2020-10-26 20:59

developer   ~0126573

How to test the effect of this change? How does it affect the existing code?

Zaher Dirkey

2020-10-26 22:39

reporter   ~0126574

before this patch, using IpHtmlPanel1.SetHtmlFromStr(SynEdit1.Lines.Text) for example, show Arabic characters as ????, by this patch it show it as it, also i tested Japanese word.
 'أبجد هوز'  
it show just question marks.
IpHTMLBidi.7z (3,906 bytes)

Zaher Dirkey

2020-10-26 22:43

reporter   ~0126575

Last edited: 2020-10-26 22:45

View 2 revisions

I think the problem is in TStringStream encoding. when using
strm:= TStringStream.Create(NewHtml);
without defining CodePage.

wp

2020-10-27 11:44

developer   ~0126581

Last edited: 2020-10-27 12:01

View 9 revisions

Here is a little code snippet which demonstates the issue:
procedure TForm1.Button1Click(Sender: TObject);
var
  s: string;
begin
  s := '<body>äöü</body>';   
  IpHtmlPanel1.SetHtmlFromStr(s);
end;
Using the unpatched IpHtmlPanel the output is 'äöü' , not 'äöü' as expected. Since the default text will probably be utf-8 encoded it is probably a good idea to change the FDocCharset from 'ISO-8859-1' to 'UTF-8' as suggested. After the change in the TIpHtml.Parse procedure the output is correct. --> Applied this in r64078.

I do not like the idea to add a codepage parameter to the SetHtmlFromStr call since this will break existing user code. OK -- there is the possibility to overload the method so that to old one is still available. But I do not think that's the way how encoding should be handled. HTML has a meta tag for it. When I replace the string in my code by
s :=
    '<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/></head>'+
    '<body>äöü</body></html>';   
the output is correct even with the old default value of FDocCharset.

There is a problem, though, - and this should be fixed - that the short form of the meta tag
<meta charset="utf-8"/>
does not work.

Instead of adding a code page parameter, couldn't we extract the code page from the string type as FPC suggests (StringCodePage(s))?

Sven Barth

2020-10-27 15:40

manager   ~0126584

> Instead of adding a code page parameter, couldn't we extract the code page from the string type as FPC suggests (StringCodePage(s))?

In that case the parameter of SetHtmlFromStr should be RawByteString (don't know if it already is), cause otherwise the RTL will trigger a runtime conversion to CP_ACP which in case of Lazarus is CP_UTF8.

Zaher Dirkey

2020-10-27 22:45

reporter   ~0126589

if I set FDocCharset := 'UTF-8' as default, but without setting codepage, it show my Arabic string like this `أبجد هوز`

if I keep FDocCharset := 'ISO-8859-1' as default, but setting codepage to CP_UTF8, it show my Arabic string like this `???? ???`

not `أبجد هوز`

So both are needed to fix.

I am using FPC 3.3.1 , Lazarus from SVN

Zaher Dirkey

2020-10-27 23:18

reporter   ~0126590

There is a bug for <meta charset="utf-8"/> in the parser, i will fix it after this issue

Zaher Dirkey

2020-10-27 23:37

reporter   ~0126592

And notice this bug for HTML have not define Meta, or BOM , In my example I added meta to start fixing parsing it (the parser).

wp

2020-10-28 00:33

developer   ~0126593

> if I set FDocCharset := 'UTF-8' as default, but without setting codepage, it show my Arabic string like this `أبجد هوز`

Is your Arabic text displayed correctly in other LCL controls? If yes it is UTF8, and I don't see why it should not display correctly in the HTMLPanel after having fixed the default FDocCharset to UTF8. If not it is encoded in some other code page and you must either convert the text to UTF8 before calling SetHtmlFromStr or you must specify the charset in the meta tag.

-------------

>if I keep FDocCharset := 'ISO-8859-1' as default, but setting codepage to CP_UTF8, it show my Arabic string like this `???? ???`

Of course - this is completely wrong. ISO-8859-1 is a European codepage. Even if you tell the stream that the encoding of your Arabic text is UTF-8 it won't fit to the European codepage.

---------

In my understanding the layouting and painting of the text to the HtmlPanel is done in UTF8. So, the FDocCharset stores the code page of the arriving text and it defines the kind of conversion to be applied. See TIpHtml.AddWord which calls ConvertEncoding from FDocCharset to UTF8.

wp

2020-10-28 00:41

developer   ~0126594

I tried this simple code to display Arabic text in the HTMLPanel (the text is the first line of the Arabic text on https://r12a.github.io/scripts/tutorial/summaries/arabic -- I don't know what it means...)
const
  html = '<body>عندما يريد العالم أن ‪يتكلّم ‬ ، فهو يتحدّث بلغة يونيكود. تسجّل الآن لحضور</body> ';

procedure TForm1.FormCreate(Sender: TObject);
begin
  IpHtmlPanel1.SetHtmlFromStr(html);
end;  


And it "looks" Arabic to me, but close comparing with the original shows that the order of the words is reversed. I can imagine that the text layout procedure was written without having Right-to-Left in mind...

Pedro Gimeno

2020-10-28 00:56

reporter   ~0126595

I concur with @PascalDragon, you can't pass a string in an arbitrary encoding unless RawByteString is used. Thus the parameter of SetIpHtmlFromStr should be RawByteString.

To keep compatibility, the optional codepage parameter could default to a value that is not a codepage. This would be a code that indicates that the input string should first be converted to CP_ACP before using it in a stream.

Patch attached.
patch-37992.diff (1,110 bytes)   
Index: components/turbopower_ipro/iphtml.pas
===================================================================
--- components/turbopower_ipro/iphtml.pas	(revision 64060)
+++ components/turbopower_ipro/iphtml.pas	(working copy)
@@ -2824,7 +2824,7 @@
     procedure DeselectAll;
     procedure SetHtml(NewHtml : TIpHtml);
     procedure SetHtmlFromFile(const AFileName: String);
-    procedure SetHtmlFromStr(NewHtml : string);
+    procedure SetHtmlFromStr(NewHtml : RawByteString; ACodePage: Integer = -99);
     procedure SetHtmlFromStream(NewHtml : TStream);
     procedure Stop;
     {$IFDEF Html_Print}
@@ -16141,11 +16141,16 @@
   end;
 end;
 
-procedure TIpHtmlCustomPanel.SetHtmlFromStr(NewHtml: string);
+procedure TIpHtmlCustomPanel.SetHtmlFromStr(NewHtml: RawByteString; ACodePage: Integer);
 var
   strm: TStringStream;
 begin
-  strm:= TStringStream.Create(NewHtml);
+  if ACodePage = -99 then
+  begin
+    SetCodePage(NewHtml, CP_ACP);
+    strm := TStringStream.Create(NewHtml);
+  end else
+    strm:= TStringStream.Create(NewHtml, ACodePage);
   try
     SetHtmlFromStream(strm);
   finally
patch-37992.diff (1,110 bytes)   

Zaher Dirkey

2020-10-28 00:58

reporter   ~0126596

It is between your hands :)
I will do more test in default os codepage as eu.
But I think it is reveal it where is the bug.

The order of RightToLeft order it is my big plan, it is complex, I left it after i finish small bugs.

Pedro Gimeno

2020-10-28 01:16

reporter   ~0126597

Note also that 'meta charset=...' is HTML5, see https://www.w3.org/TR/html401/struct/global.html#h-7.4.4.2 for what HTML 4.01 supports. I don't think IpHtml supports HTML5. The meta http-equiv="content-type" works as expected.

Sven Barth

2020-10-28 07:32

manager   ~0126598

@Pedro Gimeno: in your patch the code page of the string is not checked at all. Instead you should drop the ACodePage parameter again and simply pass the string to TStringStream.CreateRaw (instead of Create) which will retrieve the code page from the string and use that (the normal Create will already result in a conversion to CP_ACP to matter what you do)

Pedro Gimeno

2020-10-28 08:29

reporter   ~0126601

Thanks, I misunderstood how RawByteString was treated. I thought it resulted in a string with CP_NONE as code page. Since it's not the case, indeed the string's code page should be preserved and used, so here's a revised patch (you should be credited too).
patch-37992-v2.diff (927 bytes)   
Index: components/turbopower_ipro/iphtml.pas
===================================================================
--- components/turbopower_ipro/iphtml.pas	(revision 64060)
+++ components/turbopower_ipro/iphtml.pas	(working copy)
@@ -2824,7 +2824,7 @@
     procedure DeselectAll;
     procedure SetHtml(NewHtml : TIpHtml);
     procedure SetHtmlFromFile(const AFileName: String);
-    procedure SetHtmlFromStr(NewHtml : string);
+    procedure SetHtmlFromStr(NewHtml : RawByteString);
     procedure SetHtmlFromStream(NewHtml : TStream);
     procedure Stop;
     {$IFDEF Html_Print}
@@ -16141,11 +16141,11 @@
   end;
 end;
 
-procedure TIpHtmlCustomPanel.SetHtmlFromStr(NewHtml: string);
+procedure TIpHtmlCustomPanel.SetHtmlFromStr(NewHtml: RawByteString);
 var
   strm: TStringStream;
 begin
-  strm:= TStringStream.Create(NewHtml);
+  strm:= TStringStream.CreateRaw(NewHtml);
   try
     SetHtmlFromStream(strm);
   finally
patch-37992-v2.diff (927 bytes)   

wp

2020-10-28 13:08

developer   ~0126602

Last edited: 2020-10-28 13:17

View 2 revisions

In the initial verson of the IpHtmlPanel (before this report) the default value for FDocCharset was set to an empty string. In r64078 this was changed to the string 'UTF-8'. When the html text contains meta data with codepage information, the FDocCharset is overwritten by this value.

OK, but a few lines later, in ParseHead, it is checked whether the encoding is supported by the Lazarus LConvEncoding unit. I don't know why, but when the FDocCharset was found to be 'UTF-8' the string was erased. This had the consequence that later, in TIpHtml.AddWord, no codepage conversion is executed.

I really have no idea what this codepage check in ParseHead is good for. Maybe it checks against a non-supported encoding. In this case, the return value of Lst.IndexOf(FDocCharset) should be checked against -1 instead of 0 (the position of 'UTF-8' in the Lst).

I wrote a test program which uses a CP1250-encoded html file with and without meta data. My system CP is 1252, so I think this case is rather general. After replacing the above mentioned '0' by '-1' all three string usage methods of the demo work correctly:
 - method 1: use meta data
 - method 2: read the CP1250 ansi file and convert the string to UTF8 by ConvertEncoding before passing it to SetHtmlFromStr
 - method3: read the CP1250 file to a codepage-aware string for CP1250 and pass this to SetHtmlFromStr. This works without introducing RawByteString.

Zaher, please check r64080.

wp

2020-10-28 13:17

developer   ~0126603

Sven Barth

2020-10-28 13:35

manager   ~0126604

> - method3: read the CP1250 file to a codepage-aware string for CP1250 and pass this to SetHtmlFromStr. This works without introducing RawByteString.

It works, yes, because that's the point of the codepage aware string type, however it will always introduce a conversion from the codepage to CP_ACP (UTF-8 in case of Lazarus). I'm not saying that this is incorrect behaviour for SetHtmlFromStr, but it should be kept in mind at least.

wp

2020-10-28 17:25

developer   ~0126607

Another idea motivated by
  if FDocCharset<>'' then
    Value := ConvertEncoding(Value, FDocCharset, 'UTF-8');
of TIpHtml.AddWordEntry - only non-UTF-8 encodings are passed to the ConvertEncoding routine, or in other words: the default encoding indicated by an empty FDocCharset is UTF8. This means that the default value in Parse should be an empty string, and the Lst.IndexOf(FDocCharset) should check against 0 again. With these modifications my test program work correctly, too.

I am attaching a patch relative to the current r64080 since I don't want to commit too many experimental code to trunk.
iphtml.pas.patch (750 bytes)   
Index: components/turbopower_ipro/iphtml.pas
===================================================================
--- components/turbopower_ipro/iphtml.pas	(revision 64080)
+++ components/turbopower_ipro/iphtml.pas	(working copy)
@@ -5799,7 +5799,7 @@
   {$IFDEF IP_LAZARUS}
   Lst := TStringList.Create;
   GetSupportedEncodings(Lst);
-  if Lst.IndexOf(FDocCharset)=-1 then
+  if Lst.IndexOf(FDocCharset) = 0 then  // clear in case of UTF-8 to avoid conversion
     FDocCharset := '';
   Lst.Free;
   {$ENDIF}
@@ -7840,7 +7840,7 @@
     ListLevel := 0;
     StartPos := CharStream.Position;
     {$IFDEF IP_LAZARUS}
-    FDocCharset := 'UTF-8';
+    FDocCharset := ''; //UTF-8';
     FHasBOM := false;
     Ch1 := GetChar;
     Ch2 := GetChar;
iphtml.pas.patch (750 bytes)   

Zaher Dirkey

2020-10-29 11:33

reporter   ~0126630

Last edited: 2020-10-29 11:34

View 2 revisions

from SVN I tested loading file, it work, but when I set it from SynEdit, it fail, it give me ????
And that the main problem, setting html it from string

Zaher Dirkey

2020-10-29 11:58

reporter   ~0126632

I tested Pedro patch, and it is work fine with last svn update, I prefer it over my patch
strm:= TStringStream.CreateRaw(NewHtml);

wp

2020-10-29 19:20

developer   ~0126646

> but when I set it from SynEdit, it fail, it give me ????

Is this the program that you posted in remark 0126574? (If not, please post it). It is working correctly for me even if Pedro's patch is NOT applied. What is going on here? I am on Windows 10 (64bit), Laz trunk/FPC 3.2.0 (32bit). What is your OS, FPC-version, bitness?
IpHtmlBiDi-output-wp.png (6,406 bytes)   
IpHtmlBiDi-output-wp.png (6,406 bytes)   

Zaher Dirkey

2020-10-29 22:48

reporter   ~0126647

@Yes it is work too, from last SVN and your patch (without Pedro patch), but i didn't understand it yet

wp

2020-10-30 00:25

developer   ~0126648

What I do not understand is that you always wrote that you had to define the codepage of the stringstream although the FDocCharset was already changed to default to 'UTF-8'. It was working for me already after defaulting FDocCharset to 'UTF-8', even without the stringstream codepage modification.

The codepage modification is not required because the input string of your demo is already UTF8. The old FDocCharset, 'ISO-8859-1', had triggered a conversion of the inputstring on the assumption that it were ISO-8859-1 which, of course, leads to wrong results.

In r64088 I committed the patch from note 0126607, i.e. the default FDocCharset is now an empty string. This works also because the ConvertEncoding call is bypassed in this case. Please test. Also try to pass non-UTF8 strings to the panel. I did test this case (see demo at note 0126603, but maybe I missed something.

I'll resolve when it is successful.

Zaher Dirkey

2020-10-30 10:04

reporter   ~0126651

I am thinking

I need more testing to see why your removing the convert resloved the problem, as i imagine Lazarus is already utf8 inside, from SynEdit to ipHTML,
By omitting converting, that mean non utf8 not converted to non utf8, that mean i should test what inside that string.

I still prefer to add pedro patch too, but also need to know why `TStringStream.Create(` did convert while it is already utf8
strm:= TStringStream.CreateRaw(NewHtml);

Zaher Dirkey

2020-10-30 10:11

reporter   ~0126652

StringCodePage(NewHtml) return 65001 it is utf8
What strm:= TStringStream.Create(NewHtml) did? why it changing the string to make it wrong (before last fix)?

ah

is `ConvertEncoding(Value, FDocCharset, 'UTF-8')` from utf8 corrupt the utf8 string?
Now I understand it.

Pedro Gimeno

2020-10-30 15:27

reporter   ~0126662

I'm no longer sure my patch is correct or desirable. Here are my thoughts.

In order to be able to parse the HTML, the component needs to have the internal representation in an encoding it can be sure that provides the necessary encoding. If the input string is in some encoding that doesn't have consecutive ASCII characters, like, say, UTF-16 (or EBCDIC, should it be supported), then the parser won't be able to do its job unless the input is first converted to something that guarantees consecutive ASCII characters, like UTF-8.

Therefore, a conversion on input from the original encoding to UTF-8 is desirable. So, my patch is probably a bad idea. What to do on output is still a question for me, because I don't fully understand the workings of the component.

Zaher Dirkey

2020-10-30 15:50

reporter   ~0126667

@Pedro the parser use the stream as Ansi for, and leave non ansi to the Lazarus to paint it, if the stream not Ansi, be sure it is not double byte for example (We need to test it), I will test unicode (2 byte) string as file.

Zaher Dirkey

2020-10-30 15:56

reporter   ~0126668

Last edited: 2020-10-30 15:58

View 2 revisions

From this code, only Ansi and UTF8 allowed, Parser char as ansi, and leave non ansi to TextOut (bypassing it)
    if (Ch1=#$FE) and (Ch2=#$FF) then begin
      FDocCharset := 'UCS-2BE';
      raise Exception.CreateFmt('%s document encoding not supported!',[FDocCharset]);
    end else
    if (Ch1=#$FF) and (ch2=#$FE) then begin
      FDocCharset := 'UCS-2LE';
      raise Exception.CreateFmt('%s document encoding not supported!',[FDocCharset]);
    end else
    if (Ch1=#$EF) and (ch2=#$BB) then begin
      Ch3 := GetChar;



Now words strings will converted to UTF8 word by word from Ansi, Right?

wp

2020-10-30 17:34

developer   ~0126669

Last edited: 2020-10-30 17:42

View 2 revisions

> Now words strings will converted to UTF8 word by word from Ansi, Right?

No, it does not get this far. Checking of the BOM happens at the very beginning of the scanning process. The scanner refuses to continue when utf-16 content is found because it relies on having single-byte characters only. If handling of UTF-16 files or streams is required the scanner must be rewritten in a way that it can handle double-byte characters (char --> widechar). If the content exists as a unicode string it can be displayed if the string is converted to utf8 before passing it to SetHtmlFromStr() (and in this case the charset tag should be absent because it would trigger the ConvertEncoding function).

wp

2020-10-30 17:58

developer   ~0126670

> is `ConvertEncoding(Value, FDocCharset, 'UTF-8')` from utf8 corrupt the utf8 string?

When the input string, Value, is utf-8 the result will be damaged when FDocCharset <> utf-8, because this function takes every char of the input string, assumes it has the encoding given by FDocCharset and replaces it by the utf-8 codepoint of that character.

Zaher Dirkey

2020-10-30 21:12

reporter   ~0126672

Here,
  if FDocCharset<>'' then
    Value := ConvertEncoding(Value, FDocCharset, 'UTF-8');

it convert each string added to utf8, that mean all content really after loading from stream/string is utf8.
Input it can be Ansi or UTF8, because parser now only handle single byte, but pass others to addword.

now, it is same, converting the whole string to utf8 and set it to ipHTML.SetHtmlFromStr as utf8, or whatever, it finally being converted to utf8

btw it is fixed now

>>When the input string, Value, is utf-8 the result will be damaged when FDocCharset <> utf-8, because this function takes every char of the input string, assumes it has the encoding given by FDocCharset and replaces it by the utf-8 codepoint of that character.

That descripe the original bug for this issue

Pedro Gimeno

2020-10-30 23:21

reporter   ~0126673

I guess those who want to pass the raw string can do this before passing it to SetHtmlFromStr, to prevent conversion:

  SetCodePage(S, CP_NONE, False);
  IpHtmlPanel1.SetHtmlFromStr(S);


So I guess that there's nothing else to do and this issue can be closed.

wp

2020-10-31 00:25

developer   ~0126674

ok, resolving. Please do a final test and close.

Zaher Dirkey

2020-10-31 09:45

reporter   ~0126675

Last edited: 2020-10-31 09:45

View 2 revisions

I tested with windows-1252 file charset while my system is windows-1256, it is work fine, now only this patch to fix handling charset
 <meta charset="UTF-8"> 

nothing mention related to HTML5 in,
https://www.w3schools.com/html/html_charset.asp

or in validators
iphtml.pas09.patch (1,421 bytes)   
Index: components/turbopower_ipro/iphtml.pas
===================================================================
--- components/turbopower_ipro/iphtml.pas	(revision 64091)
+++ components/turbopower_ipro/iphtml.pas	(working copy)
@@ -5717,18 +5717,21 @@
     Name := FindAttribute(htmlAttrNAME);
     Content := FindAttribute(htmlAttrCONTENT);
     {$IFDEF IP_LAZARUS}
-    if SameText(HttpEquiv, 'content-type') and not FHasBOM then begin
-      j := pos('charset=', lowercase(Content));
-      if j>0 then begin
-        j := j+8;
-        i := j;
-        while (j<=Length(Content)) do begin
-          if Content[j] in [' ',';','"',','] then
-            break;
-          inc(j);
+    if not FHasBOM then begin
+      if SameText(HttpEquiv, 'content-type') then begin
+        j := pos('charset=', lowercase(Content));
+        if j>0 then begin
+          j := j+8;
+          i := j;
+          while (j<=Length(Content)) do begin
+            if Content[j] in [' ',';','"',','] then
+              break;
+            inc(j);
+          end;
+          fDocCharset := copy(content, i, j-i);
         end;
-        fDocCharset := copy(content, i, j-i);
-      end else
+      end
+      else
         fDocCharset := FindAttribute(htmlAttrCHARSET);
       if pos('windows', Lowercase(fDocCharset)) = 1 then
         fDocCharset := NormalizeEncoding(StringReplace(fDocCharset, 'windows', 'cp', [rfIgnoreCase]));
iphtml.pas09.patch (1,421 bytes)   

wp

2020-10-31 11:06

developer   ~0126676

Thanks for the new patch. Applied in r64092.

But please, when you want to respond to a "resolved" (green) report you should be aware that the developer may not expect that something has been added to the report, and thus the change may not be noticed. It is better to "Reopen" the report so that the color of the report changes making it evident that something has been added here.

I think this bug report is finished now. Please test again, and then close it.

Zaher Dirkey

2020-10-31 11:22

reporter   ~0126677

Thank you

Issue History

Date Modified Username Field Change
2020-10-26 16:59 Zaher Dirkey New Issue
2020-10-26 16:59 Zaher Dirkey File Added: iphtml.pas08.patch
2020-10-26 17:01 Zaher Dirkey Note Added: 0126571
2020-10-26 20:59 Juha Manninen Note Added: 0126573
2020-10-26 22:39 Zaher Dirkey Note Added: 0126574
2020-10-26 22:39 Zaher Dirkey File Added: IpHTMLBidi.7z
2020-10-26 22:43 Zaher Dirkey Note Added: 0126575
2020-10-26 22:45 Zaher Dirkey Note Edited: 0126575 View Revisions
2020-10-27 11:44 wp Note Added: 0126581
2020-10-27 11:45 wp Note Edited: 0126581 View Revisions
2020-10-27 11:45 wp Note Edited: 0126581 View Revisions
2020-10-27 11:48 wp Note Edited: 0126581 View Revisions
2020-10-27 11:48 wp Assigned To => wp
2020-10-27 11:48 wp Status new => assigned
2020-10-27 11:48 wp Status assigned => feedback
2020-10-27 11:48 wp LazTarget => -
2020-10-27 11:51 wp Note Edited: 0126581 View Revisions
2020-10-27 11:56 wp Note Edited: 0126581 View Revisions
2020-10-27 11:57 wp Note Edited: 0126581 View Revisions
2020-10-27 11:58 wp Note Edited: 0126581 View Revisions
2020-10-27 12:01 wp Note Edited: 0126581 View Revisions
2020-10-27 15:40 Sven Barth Note Added: 0126584
2020-10-27 22:45 Zaher Dirkey Note Added: 0126589
2020-10-27 22:45 Zaher Dirkey Status feedback => assigned
2020-10-27 23:18 Zaher Dirkey Note Added: 0126590
2020-10-27 23:37 Zaher Dirkey Note Added: 0126592
2020-10-28 00:33 wp Note Added: 0126593
2020-10-28 00:41 wp Note Added: 0126594
2020-10-28 00:56 Pedro Gimeno Note Added: 0126595
2020-10-28 00:56 Pedro Gimeno File Added: patch-37992.diff
2020-10-28 00:58 Zaher Dirkey Note Added: 0126596
2020-10-28 01:16 Pedro Gimeno Note Added: 0126597
2020-10-28 07:32 Sven Barth Note Added: 0126598
2020-10-28 08:29 Pedro Gimeno Note Added: 0126601
2020-10-28 08:29 Pedro Gimeno File Added: patch-37992-v2.diff
2020-10-28 13:08 wp Note Added: 0126602
2020-10-28 13:17 wp Note Edited: 0126602 View Revisions
2020-10-28 13:17 wp Note Added: 0126603
2020-10-28 13:17 wp File Added: 37992 - IpHtmlPanel Encoding.zip
2020-10-28 13:35 Sven Barth Note Added: 0126604
2020-10-28 17:25 wp Note Added: 0126607
2020-10-28 17:25 wp File Added: iphtml.pas.patch
2020-10-29 11:33 Zaher Dirkey Note Added: 0126630
2020-10-29 11:34 Zaher Dirkey Note Edited: 0126630 View Revisions
2020-10-29 11:58 Zaher Dirkey Note Added: 0126632
2020-10-29 19:20 wp Note Added: 0126646
2020-10-29 19:20 wp File Added: IpHtmlBiDi-output-wp.png
2020-10-29 22:48 Zaher Dirkey Note Added: 0126647
2020-10-30 00:25 wp Note Added: 0126648
2020-10-30 00:26 wp Status assigned => feedback
2020-10-30 10:04 Zaher Dirkey Note Added: 0126651
2020-10-30 10:04 Zaher Dirkey Status feedback => assigned
2020-10-30 10:11 Zaher Dirkey Note Added: 0126652
2020-10-30 15:27 Pedro Gimeno Note Added: 0126662
2020-10-30 15:50 Zaher Dirkey Note Added: 0126667
2020-10-30 15:56 Zaher Dirkey Note Added: 0126668
2020-10-30 15:58 Zaher Dirkey Note Edited: 0126668 View Revisions
2020-10-30 17:34 wp Note Added: 0126669
2020-10-30 17:42 wp Note Edited: 0126669 View Revisions
2020-10-30 17:58 wp Note Added: 0126670
2020-10-30 21:12 Zaher Dirkey Note Added: 0126672
2020-10-30 23:21 Pedro Gimeno Note Added: 0126673
2020-10-31 00:25 wp Status assigned => resolved
2020-10-31 00:25 wp Resolution open => fixed
2020-10-31 00:25 wp Fixed in Revision => r64078, 64079, 64080, 64088
2020-10-31 00:25 wp Note Added: 0126674
2020-10-31 09:45 Zaher Dirkey Note Added: 0126675
2020-10-31 09:45 Zaher Dirkey File Added: iphtml.pas09.patch
2020-10-31 09:45 Zaher Dirkey Note Edited: 0126675 View Revisions
2020-10-31 11:06 wp Note Added: 0126676
2020-10-31 11:22 Zaher Dirkey Status resolved => closed
2020-10-31 11:22 Zaher Dirkey Note Added: 0126677