-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Functionality of b_ #2726
Comments
I'm not sure this is at will. you may found a way to improve performances... |
This has been added/changed in #124 by @mozbugbox. |
The first of the commit messages is "Speedup b_() for short string for Python3", which suggests the current functionality is deliberate. The code tries latin-1 and if there is an exception uses utf-8. Given the rise of utf-8, I think we should just use utf-8. |
@j-t-1 I recommend you to further dig into the commit history if unsure about specific cases - the |
@pubpub-zz Is this equivalent to this (and if so we could change it)? |
Aka =also known as |
@j-t-1 |
Each time through the function we have an if statement to decide if a string of length zero or one is in the cache. If it is not, we have another if statement deciding whether len(s) < 2. If we remove the cache we would remove at least one if statement every time b_ is invoked. Keeping it as is, only make sense if:
To gauge 1. depends on particular PDF and use case because b_ is used in a few places.
This comment suggests we keep b_ as is. |
With regard to 1: In my experience, automated reporting frameworks and 'document to PDF' conversion tools LOVE to use a 'render every character one at a time' paradigm for creating a 'justified' text layout, and many of them just behave that way by default to simplify their implementations. Long story short, I suspect the |
Comment courtesy of @shartzog, issue py-pdf#2726.
@shartzog this is the information needed! In a future PR we could possibly add your comment above as a comment into b_:
Referencing you in the commit message. |
closes py-pdf#2726 superseed proposal py-pdf#2791
It is non-obvious why we are only caching strings of length zero (the empty string) and of length one.
There is a need to add comments to this function.
The text was updated successfully, but these errors were encountered: