-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Multi-column Float Elements (Figures, Tables, Code Blocks, etc.) #553
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
Comments
Currently elements cannot break away from their local scope. If A separate issue is that if an element (e.g. image) doesn't fit into the remaining space it will move to the next page/column leaving a blank space behind it. These two issues, while separate, must be tackled together as there are complex interactions between them. To solve the first issue I propose that we introduce a To solve the second issue I propose a new layout element The function signatures would be:
|
Algorithm for
|
In case 2 or more
|
Does this seem reasonable? @laurmaedje, @reknih Also is this the best place to discuss or do you prefer discord? I am also willing to contribute code to get this out sooner! 🙂 |
This is great. In fact, it'd be ideal. |
Do you think the primary and secondary alignments are both necessary? @Andonome |
This is the most important missing feature to make typst as powerful as LaTeX. |
I wouldn't say 'necessary', but I've found a great deal of flexibility in having both 'top' and 'bottom' options. This page looks fine, as-is, but the two elements float apart when more text is added, which matches the general format of pictures-at-bottom, and tables-on-top. I've not found tables in the centre work very often. Of course if anyone wants to get really fancy, automatic wrapping around a PNGs filled parts would be punk-as-all-heck. |
LaTeX doesn't have this ability. There is no reliable text wrapping in a multicols environment. It's a big factor which stops it having reliable output - every compile, every page needs to be checked, images moved, et c. Edit: I see I've received some silent naysayers downvoting this comment. If anyone wants to put their code where their mouth is, check out my main project, and get any 3 images (of your choosing) to float, using any macro you please. |
@Andonome I think is wrap is to be implemented it should be implemented with all these usecases in mind. Another usecase that comes to mind is that you have a central circular figure and that text should wrap around it as well. You examples are genuinely useful. Thanks! |
In you table and figure example would you want to force text to move to the next page or would it be ok for it to render in-between the two elements? |
Would a showcase be useful? I've had a bunch of ugly results with difficult elements.
It depends on the results. Either could be fine, but what's sorely lacking is the ability to return to the last page for a do-over. LaTeX can't correct previous pages, so you can get these ugly dangling single-lines of text. I've given headers a bunch of Of course here it's blocked by the General Tempo Chart, so that should have been moved to after the next paragraph. In a lot of cases, it's far more important to say 'place this element somewhere before the next subsection' than making a statement about the position. Here's another table that could have been better placed by floating anywhere else after the I don't know if there's a non-intensive way to have typst go through a bunch of options involving multiple pages, but maybe there could be a second processing option where the user understands it'll take extra time to process, but the results will make sense. Atm a full LaTeX process can take 20 minutes - that's quite doable for big pushes, but less okay when the results need fiddled with before publishing a new version. |
I have update the proposal based on your previous comments and from conversations in Discord. Here is the updated proposal if you want to have a look @Andonome : Multi-column Float Proposal.pdf I haven't thought thoroughly about your latest comment just yet but do you think that the proposal here covers those usecases |
Ok I just had another look and your usecase in incredibly useful! I might need to tweak the |
I am not sure I fully understand this point. Is this something that the algorithm is lacking or is it something that the existing Latex API cannot express. If it is the latter I will make a note on the algorithm implementation portion of the proposal otherwise I will make a note on the motivation and API section as an additional user intent |
Proposal v3: |
Proposal v4: |
This all looks fantastic. In 1.6:
It might be better to disable this by default. Nobody wants to see 2-words crawling down the side of a table. The table should be centred automatically. In fact in general, the default being 'typst chooses' is always good. Take for example the first example table. It's clearly best presented image-wide, but that won't always be obvious until the page has processed. If the floating default behaviour was for typst to choose how it floats (and only request the user states if it should be in the same section or page as something else) then it'd really help in producing unattended document production. |
I can suggest reading the Lillypond essay about problems of automated music engraving. I believe, a lot of ideas are common to any complex layout system and potentially can be applied to typst as well. tldr: Music notation is much more complicated than one can imagine. Naive approach to notation layout based on the hierarchy of containers (page→staff→lines→notes etc) simply does not work. Once in a while you will face some quirky notation like multi-staff slurs or beams, and things will get complicated. In the end, this will result in a lot of ad-hoc code, or the result will not be visually pleasing. Lillypond uses completely different approach to layout. |
I just wanted to add my +1 here. I'm trying to write up a whitepaper in IEEE format and floating tables / figures are not possible AFAIK. |
It would be lovely to see this feature implemented. |
I'm impressed by your solution Nathan! Great work! |
This looks pretty neat. Does anyone know whether it's possible to position a table spanning the width o A93C f the page in typical Typst 2-column layout with this package? |
Doesn't seem like it's possible - at least I wasn't able to. Maybe @ntjess knows a workaround? |
Im not sure if it was already discussed elsewhere but I believe that the ability to place multicolumn floats should be a feature of |
i encountered the same issue whilst using the charged-iee template, i wasn't able to put a figure containing a large / wide image at the top, spanning the two columns 🤔 having this feature or a workaround would be really great 😇 |
Any idea when this feature will be added? |
@Vivdaddy We plan to take a closer look at this for 0.12, but I can't make any promises. |
It seems like spanning a figure across all columns should be relatively straightforward to implement and it would fix 90% of all multi-column issues. Specially if the figure is at the top or bottom of a page. It would be as if a page with such a figure were a little shorter and the page break happened a bit before or after the actual page break in order to make space for the figure. I know that if this feature were implemented it would prevent me from temporarily switching back to LaTeX, and it seems a lot of people are also anxiously waiting for this (over 100 users if we go by GitHub reactions, but I suspect there are many more). Please let us know when you have updates! ❤️ |
I suspect that if it was straightforward the issue wouldn't still be open. |
This issue is about arbitrary multi-column float elements, which is a complex problem, specially if it involves arbitrary-shape text wrapping as in the last image in this comment. My objective was to point out that there is a subset of this problem space i.e. spanning an element across all columns of a page, specially at the top or bottom of a page (with no arbitrary-shape text wrapping), which is simpler to implement, and would solve the majority of use cases. I think any attempt at a solution should first focus on this. |
@laurmaedje Any progress on this feature request? :) |
I believe that the lack of support for multi-column figures and tables is the main limitation to using Typst for writing manuscripts for scientific journals. |
It depends on the field - almost nothing I submit to (in biology) uses multi-column layouts, but I need line numbers (happily that's being worked on #352 ) |
Definitely true for informatics and computer sciences where the IEEE format is quite common. Some stuff is just to large to fit in a single half-page column meaningfullly. |
I think the ideal solution, from a user's perspective, would involve adding a single parameter, tentatively called |
I'm not a mod, but I think that there are now enough "This feature is stopping me from using Typst"/"This feature is missing for XYZ support" comments in this issue. The Devs are aware of this issue, and it is as-of-now the third most upvoted issue. So instead of adding more comments of the same, I'd suggest using the emoticons to express your support for this feature. |
#place(
top,
dx: 70%,
float: true,
clearance: 0pt,
figure(
place(
auto,
dx: 0%,
float: true,
clearance: 0pt,
image("A2.png", width: 200%)
),
caption: [Visualization of Zero-Shot, Few-Shot model.] // Centered under the image
),
)
#place(
top,
float: true,
rect(height: 5pt, fill: none, stroke: none)
)
#lorem(500)
#place(
top,
float: true,
rect(height: 290pt, fill: none, stroke: none)
) |
@NeutrinoLiu and @spped2000 👋 so i've tried your examples and they did not work on my side... my reproi have installed Typst today with cargo +1.77 install --git https://github.com/typst/typst --locked typst-cli and i get the following
my Typst source is a single file, called #show: rest => columns(2, rest)
#place(
top,
dx: 105%,
float: true,
clearance: 0pt,
figure(
place(
auto,
dx: -40%,
float: true,
clearance: -8pt,
figure(
table(
align: center,
columns: (80pt, 80pt, 80pt, 80pt, 80pt),
[Primitive], [Rendering Quality], [Rendering Speed], [Accessibility], [Storage],
[3DGS 3dgs], [high], [high (>100fps)], [relatively easy], [middle],
[NeRF nerf], [high], [low (\<10fps)], [relatively easy], [low],
[point cloud], [depends], [middle], [easy], [high],
[mesh], [depends], [high], [poor], [middle]
)
),
),
caption: [Comparison between different 3D representation]
),
)
#lorem(500)
#place(
top,
float: true,
rect(height: 87pt, fill: none, stroke: none)
) then i compile this with typst compile main.typ main.pdf |
Good news: #5017 |
Hey guys, I'm probably missing something but can I use the new layout engine to wrap text around figures? The wrap-it package says that it's only relevant as long as this issue isn't resolved. Since it is now, does this mean I can actually wrap text around figures? (and how?) Or is it still not possible and the package documentation should be updated? |
@sschuldenzucker Text wrapping around figures at the side was not part of the 0.12 work on floating placement. This subfeature was also proposed in this issue, but it was too large of an issue to be actionable. Side-wrapping is now tracked by #5181. |
Uh oh!
There was an error while loading. Please reload this page.
Supersedes: #137.
I want to be able to break the column rules for figures and tables to the full size of the page and I want to be able to float these elements. I believe these two must be tackled together as you can see in the motivating examples
The text was updated successfully, but these errors were encountered: