Correct documentation of line dictionary #2958
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JorjMcKie
force-pushed
the
clarify-line-dictionary
branch
from
12847c8 to
03a6595
Compare
jamie-lemon
requested changes
Jan 8, 2024
docs/shape.rst
Outdated
| :arg int expandtabs: controls handling of tab characters *\t* using the *string.expandtabs()* method **per each line**. | ||
| :arg float lineheight: a factor to override the line height calculated from font properties. If not `None`, a line height of `fontsize * lineheight` will be used. | ||
|
|
||
| :arg int expandtabs: controls handling of tab characters `\t` using the `string.expandtabs()` method **per each line**. |
There was a problem hiding this comment.
The backslash t here will need two backticks on either side (not one) to faithfully display.
docs/shape.rst
Outdated
|
|
||
| :arg float stroke_opacity: *(new in v1.18.1)* set transparency for stroke colors. Negative values and values > 1 will be ignored. Default is 1 (intransparent). | ||
| :arg float fill_opacity: *(new in v1.18.1)* set transparency for fill colors. Default is 1 (intransparent). Use this value to control transparency of the text color. Stroke opacity **only** affects the border line of characters. | ||
|
|
||
| :arg int rotate: requests text to be rotated in the rectangle. This value must be a multiple of 90 degrees. Default is 0 (no rotation). Effectively, four different values are processed: 0, 90, 180 and 270 (= -90), each causing the text to start in a different rectangle corner. Bottom-left is 90, bottom-right is 180, and -90 / 270 is top-right. See the example how text is filled in a rectangle. This argument takes precedence over morphing. See the second example, which shows text first rotated left by 90 degrees and then the whole rectangle rotated clockwise around is lower left corner. | ||
| :arg int rotate: requests text to be rotated in the rectangle. This value must be a multiple of 90 degrees. Default is 0 (no rotation). Effectively, four the values 0, 90, 180 and 270 (= -90) are processed, each causing the text to start in a different rectangle corner. Bottom-left is 90, bottom-right is 180, and -90 / 270 is top-right. See the example how text is filled in a rectangle. This argument takes precedence over morphing. See the second example, which shows text first rotated left by 90 degrees and then the whole rectangle rotated clockwise around is lower left corner. |
There was a problem hiding this comment.
"four the values" -> "four of the values" or just "four values". Also we could back tick all the numbers as it might look nicer?
docs/textpage.rst
Outdated
| .. [#f1] Image specifications for a PDF page are done in a page's (sub-) :data:`dictionary`, called *"/Resources"*. Resource dictionaries can be **inherited** from the page's parent object (usually the :data:`catalog`). The PDF creator may e.g. define one */Resources* on file level, naming all images and all fonts ever used by any page. In these cases, :meth:`Page.get_images` and :meth:`Page.get_fonts` will return the same lists for all pages. | ||
| .. [#f1] Image specifications for a PDF page are done in a page's (sub-) :data:`dictionary`, called `/Resources`. Resource dictionaries can be **inherited** from any of the page's parent objects (usually the :data:`catalog` -- the top-level parent). The PDF creator may e.g. define one `/Resources` on file level, naming all images and / or all fonts ever used by any page. In these cases, :meth:`Page.get_images` and :meth:`Page.get_fonts` will consequently return the same lists for all pages. If desired, this situation can be reverted using :meth:`Page.clean_contents`. After execution, the page's object definition will show fonts and images that are actually used. | ||
|
|
||
| .. [#f2] The coordinate systems of MuPDF and PDF are different in that MuPDF uses the page's top-left point as (0,0). In PDF, this is the bottom-left point. Therefore, the positive direction for MuPDF's y-axis is **from top to bottom**. This causes the sign change for the sine value here: a **negative** value indicates anti-clockwise rotation of the text. |
There was a problem hiding this comment.
backtick (0,0) , just to look nicer?
Correct and clarify line dict and others Document "lineheight" parameter in "insert_textbox()". Correct documentation of line dictionary The explanation of the text writing direction vector was incomplete / incorrect. The sign of trigonometric sine value appears reversed because of MuPDF's coordinate system.
JorjMcKie
force-pushed
the
clarify-line-dictionary
branch
from
03a6595 to
ad58d09
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The explanation of the text writing direction vector was incomplete / incorrect. The sign of trigonometric sine value appears reversed because of MuPDF's coordinate system.