kygoh
kygoh
Further trials with autocomplete widget on: - Django==3.2.11 - django-autocomplete-light==3.8.2 - django-nested-admin==3.4.0 Action | ModelAdmin.autocomplete_fields | django-autocomplete-light --|--|-- add first inline row | widget duplicated; see https://github.com/theatlantic/django-nested-admin/issues/154#issue-481266637 | no issue...
The test case [`test_box_decoration_break_block_clone`](https://github.com/Kozea/WeasyPrint/blob/8aecf3853490d271115acf7fe271a43897651644/tests/layout/test_block.py#L616-L666) has: https://github.com/Kozea/WeasyPrint/blob/8aecf3853490d271115acf7fe271a43897651644/tests/layout/test_block.py#L621-L622 If margins should be repeated, does it mean `paragraph.margin_top` in page 2 should be 5? Does this contradict with the test? https://github.com/Kozea/WeasyPrint/blob/8aecf3853490d271115acf7fe271a43897651644/tests/layout/test_block.py#L651-L656
Code and test cases until commit d29ba8c in PR #2056 seems to imply `content_box_x` function has to take into account `direction: rtl;` when called by: - `TableBox` - `TableCellBox` but...
The WeasyPrint test states that: > The two tables should be identical: The 2 rendered tables in each of the following 2 tests are not exactly identical: * test_border_collapse_bidi_border_top *...
> If you find a way to handle rtl border collapse without changing `*_box_x` functions Currently changing `content_box_x` to: https://github.com/Kozea/WeasyPrint/blob/2b0930c601b7f4fd9a9130e5881f3326bbe8a9a7/weasyprint/formatting_structure/boxes.py#L172-L179 appears to "solve" #2055 and has not failed any test...
> If you find a way to handle rtl border collapse without changing `*_box_x` functions Didn't change `*_box_x` functions but handled rtl for TableCellBox in [avoid_collisions](https://github.com/Kozea/WeasyPrint/blob/c4e70e221bd91ca822907ecac764e5198b087d0d/weasyprint/layout/float.py#L124-L231) as special case.
Commit 8ef14df also added test case based on https://github.com/Kozea/WeasyPrint/pull/2058#issuecomment-1932436107
> adding some code in `draw` is a workaround to fix the workaround I would disagree that the code added to `draw` is a workaround but rather a deliberate attempt...
> If you think that your code is ready to review After putting in more thoughts, I would like to appeal to you to reconsider commit bb14490 or something along...
> The drawing step always gets left-to-right structures for borders and column widths/positions, where x is the horizontal position from the left edge of the page, according to the common...