- Replace manual RTL with automatic rtl detection
- Handle arabic presentation form with goarabic library
- fix character width calculation problem for special characters with variable lengths in different presentation forms
- Write unit tests and add sample arabic fonts
Appy rtl #41
hmmftg/appy-rtl into main
Codecov Report
Patch coverage: 91.66% and project coverage change: +0.41 🎉
Comparison is base (
1f4411a) 79.40% compared to head (bfc3a7b) 79.81%.
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@ Coverage Diff @@
## main #41 +/- ##
==========================================
+ Coverage 79.40% 79.81% +0.41%
==========================================
Files 32 33 +1
Lines 7547 7527 -20
==========================================
+ Hits 5993 6008 +15
+ Misses 1228 1200 -28
+ Partials 326 319 -7
| Impacted Files | Coverage Δ | |
|---|---|---|
| font.go | 51.41% <0.00%> (-0.15%) |
⬇️ |
| fpdf.go | 82.94% <85.71%> (+0.82%) |
⬆️ |
| rtl.go | 100.00% <100.00%> (ø) |
|
| util.go | 71.86% <100.00%> (-2.14%) |
⬇️ |
☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.
thanks for the PR (and apologies for the belated answer).
I have a couple of comments, see below, but also one here:
instead of adding the fonts that exercize RTL text in this repository, could we instead add them in a dedicated repository ?
see, e.g., what I did for other fonts:
(and, what are the LICENSE requirements of that new font ?)
finally: your PR makes Fpdf automatically detect whether a piece of text is RTL (or LTR).
this introduces inconsistency with the RTL and LTR public methods of Fpdf.
how would you think we should resolve this ?
thanks again.
please remove
@ -2426,6 +2428,11 @@ func (f *Fpdf) Bookmark(txtStr string, level int, y float64) {
f.outlines=append(f.outlines,outlineType{text:txtStr,level:level,y:y,p:f.PageNo(),prev:-1,last:-1,next:-1,first:-1})
please document this new function.
also, do we really need to export it ?
please remove.
please keep this section.
please document this new function.
also: do we need to export it ?
also: acronyms in Go are upper case. (ie: it should read isRTL)
@ -0,0 +13,4 @@
*ACTIONOFCONTRACT,NEGLIGENCEOROTHERTORTIOUSACTION,ARISINGOUTOF
*ORINCONNECTIONWITHTHEUSEORPERFORMANCEOFTHISSOFTWARE.
*/
packagefpdf
please add the needed LICENSE blurb.
that could be simplified to:
bomState:=unicode.IgnoreBOMifbom{bomState=unicode.UseBOM}
please remove the commented out code.
Hi, thanks for your attention
I have to replace those 3rd party fonts with globally free fonts with nearly full unicode coverage I think, ie arial
As we experienced in text editors and tools that support rtl, they act smart about rtl detection and it sounds okay, they check first letter of first word and decide rtl/ltr for the whole paragraph for example if I started my paragraph with an rtl character and may be I have a few ltr words in my paragraph, then I'm writing in an rtl language and there is no doubt, and vice versa. so I think a developer who uses this library should not switch between rtl and ltr for each paragraph, you can test it with any os and any rtl keyboard layout and write something to see behavior of cursor, it comes up with years of usage and feedback and we are using it daily in sms, email, documents and else.
I'll check the comments and fix them by tomorrow.
I am definitely not against having something automatic.
what I was pointing at was that if we were to add the automatic LTR/RTL detection based on text content, then the old API would need to be adapted.
also, you hard-code a given reverse-strings function (or, rather, you replaced one hard-coded one with another one).
but (and I don't claim to be an expert there), what about all the other RTL scripts ? (e.g. Adlam, Hanifi Rohingya, Hebrew, Mandaic, Mende Kikakui, N’Ko, Old Hungarian, ...)
are those handled the same ?
shouldn't we instead provide a way for users to provide their own "reverse-strings" function ?
or a map of "script -> reverse-strings" ? (in case each script needs a particular reverse-strings function and there are multiple scripts in a given document)
I haven't forgotten about this.
(but I won't be able to properly review it before Thursday. sorry about that)
please remove this file and its .vscode parent directory.
// TODO(hmmftg): check why different presentations of the same arabic character have equal widths
but I must say I am not sure to understand what the comment is supposed to convey :)
@ -2438,3 +2443,2 @@
x-=f.GetStringWidth(txtStr)
}
x-=f.GetStringWidth(txtStr)
txt2=f.escape(utf8toutf16(txtStr,false))
instead of hard-coding this to use goarabic.FixArabic, couldn't we rather let users register their own RTL function ?
this would also fix my previous comment from https://github.com/go-pdf/fpdf/pull/41#issuecomment-1576857551
(even if we would still have to fix the API discrepancy)
WDYT ?
f.isRTL = isRTL(txtStr)
@ -2438,3 +2443,2 @@
x-=f.GetStringWidth(txtStr)
}
x-=f.GetStringWidth(txtStr)
txt2=f.escape(utf8toutf16(txtStr,false))
Ok, know I get what do you mean! we elastically let other each user with each rtl mechanisem choose it's own way
it's been fixed and comment was forgotten sorry
ping ?
unless I am mistaken, I don't think my comment in https://github.com/go-pdf/fpdf/pull/41#discussion_r1236508693 has been addressed.
- fpdf.go
- go.mod
- go.sum
- pdf/reference/Fpdf_AddUTF8Font.pdf
View command line instructions
Manual merge helper
Use this merge commit message when completing the merge manually.
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?