[Question] Feature ideas

[kroozo]

[Question] Feature ideas

[rodrigorc]

Hi, @kroozo!

Thank you for your comments! You can split or join issues as you see fit, this is just a hobby project, not a job, no need to be formal.

About your points:

1. Un-needed lines. I do my modeling in Blender. There is an option in Blender named "Dissolve edges" that will make the edge disappear for the purposes of modelling and exporting. That said, since Papercraft 2.1 there is an option "Document properties / Model / Folds / Hidden fold angle" that you can set to hide edges less than a given angle. You can still split them, but if they are joint, then they will be invisible. That is a global option, you cannot apply that to single edges yet.

2. Printable edge IDs. This has been requested before, and I think that it has to be done. I hesitated before because I didn't want to meddle with text, overlaps, fonts, styles, sizes, etc. Do you think it would be useful to show them on the preview? Or would it be enough just to print them on the PDF?

3. Fold in the SVG. But this is already done, I think. The lines are in the SVG in separated layers, so that you can print one layer and use the other two for your cutting machine (or something like that, I don't have a cutting machine). The tricky thing is that these layers are hidden by default, maybe that's why you didn't notice those? Or would you like something different?

4. Removing individual flaps. Ah, when I don't like a flap, I leave it there and then when cutting I just cut it off. I guess that may be inconvenient if you have a cutting machine. I guess we could have a new mechanism when in "Tab mode" that hides it, maybe by holding the "shift" key? The "shift" key already does something special in "Face mode" and in "Edge mode", but not in "Tab mode".

5. Removing/Hiding faces. Again, from Blender that is trivial. But having the unwanted faces all together with all the unwanted folds, and moving them out of the paper seems like a good enough solution. They are still shown in the 3D model, however. The problem with actually hiding them is: if you change your mind how do you get them back?

Some of these things could be solved by adding a menu to edit the "edge properties" separated for each edge, but I'm hesitant to add those. Currently all options are global, so "what you see is what there is" (WYSIWTI?), there is no hidden information anywhere. Adding per-edge options could mess that model. Imagine that you change your global tab-width and suddenly some tabs will not update because there is some option somewhere that overrides it. I guess that we could design a good UI around edge/face options, but I'm not sure how... Using color codes may not play nice with background textures.

About helping with testing that will be great. Can you tell me what Operating System you are using? Also, are you able to build the version yourself or would you need testing builds (no problem either way)?

I think I will prioritize items 2 and 4... stay tuned!

[rodrigorc]

That was some quick test!

Let me think of point 2 now, that will take quite some more time...

[rodrigorc]

I agree that the edge-id-range is not very good. I asked some people around and they had some difficulty grasping the concept and then the utility of it. The "A-123" was much easier to get.

About your further points:

• Remove the dash. I think some separator is needed. If I see "A123" I will tend to look for another edge labelled the same "A123", but "X123" will look to different. Also the "011" and the "I10" would look kind of similar. I think a colon looks nice and is shorter than a dash: "A:123". With this I think the ending dot is no longer needed, the letter and colon mark the way. There is still some theoretical partial ambiguity but I think they are not worth it ("I:1" upside down is still "I:1"!).
• Mess in small tabs. You are right, if the id inside a flap is next to the fold line instead of next to the cut line, there is more room. So done! That helps a bit with the mess, particularly with triangular tabs. And they will be all parallel. I could move them inside the model itself, but that could make things worse, depending on the model. This has the nice side-effect that when the ids are outside, in a triangular flap, they are now parallel, too.
• Position of the piece label. Indeed, I was using the center of the bounding box when inside, and the top of the bounding box when outside. Not very nice. I have changed to:
  • When outside, just at the top of the highest vertex.
  • When inside, in the center of mass of the biggest flat-face (flat-face are the faces before tessellation).
    Naturally, the biggest flat-face may also be concave, but it should be much less noticeable.

Also I sorted the piece IDs by number of faces (after tessellation), so the piece with the most faces will be the "A" and that with fewest will be the "ZZ". This makes it easier to navigate the model, but also means that longer IDs are in potentially smaller pieces. It could be changed to "pieces by area" or "pieces by flat-faces" or "by page", but I don't think it matters too much.

Here are a couple of picture from my Pikachu model, with the edge-ids inside (note how the "A" goes outside of my extremely concave flat-face):

And with the edge-ids outside:

I'm quite happy with the looks of it 😎.

I did find myself sweeping around the edges of island quite a lot, to see if there are / where are new pieces, not edges to already existing islands. It may be helpful to be able to briefly show all connections of an island.
That can be a useful tool, maybe holding "Alt"? But I don't know how easy it would be. Would you mind opening a separate issue for this?

[kroozo]

Anyway I think you are right, it is too near, I've added a bit of extra separation.

Looks better!

I think this issue is mostly done and can be closed, do you agree?

I do. There might be a few things in here, that are interesting, but this has been a rather long (but quite fun) thread with a lot going on in it, I think we're better of just opening another issue if something resurfaces during usage.

Thanks for the effort, you've made some awesome stuff here :)

[kroozo]

Thank you for your comments! You can split or join issues as you see fit, this is just a hobby project, not a job, no need to be formal.

Yep, exactly why it should be how its comfortable for you ;)

1. Un-needed lines. I do my modeling in Blender. There is an option in Blender named "Dissolve edges" that will make the edge disappear for the purposes of modelling and exporting. That said, since Papercraft 2.1 there is an option "Document properties / Model / Folds / Hidden fold angle" that you can set to hide edges less than a given angle. You can still split them, but if they are joint, then they will be invisible. That is a global option, you cannot apply that to single edges yet.

Ah, sorry, I must be blind, and I even read through docs. This helps a lot.
I don't really get the number through. I can see that a perfectly flat surface is 0, and others seem to be the external angle of the fold (to the line). Is this calculated by 180-internal angle?

And yes, single edge application would still be welcome, but it's much less of an issue.

2. Printable edge IDs. This has been requested before, and I think that it has to be done. I hesitated before because I didn't want to meddle with text, overlaps, fonts, styles, sizes, etc.

I understand that wholeheartedly. :)

Do you think it would be useful to show them on the preview? Or would it be enough just to print them on the PDF?

My first instinct would be that they just clutter the preview.
If you plan to make the font customizable it might make sense, but then you'd need a knob somewhere to hide them. If this was work, I'd say the MVP is a preset font, and not visible on the preview.

They are however needed on the png and svg output as well, on a separate layer on the svg.

But now I just realized that printing registration marks would also help, otherwise you need to plot with a pen :)

3. Fold in the SVG. But this is already done, I think. The lines are in the SVG in separated layers, so that you can print one layer and use the other two for your cutting machine (or something like that, I don't have a cutting machine). The tricky thing is that these layers are hidden by default, maybe that's why you didn't notice those? Or would you like something different?

Yes, this is good, and that is why I said its easy to do post processing. Basically what I was looking for is customizing these lines to make them dashed. Basically after I set the dash pattern in inkscape, this

<path style="fill:none;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter" id="foldm__3" d="
...
" />

becomes this:

<path style="fill:none;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:6,3;stroke-dashoffset:0" id="foldm__3"
d="
...
" />

This might be useful if people don't have means to score (some machines seem to advertise this separately, through god knows why would it be any different from cutting with a low blade setting), or if you prefer to actually perforate instead of scoring. I found that for thicker paper this gives easier, cleaner, straighter folds, especially for mountain folds, although admittedly on the expense of breaking through the visible surface.

4. Removing individual flaps. Ah, when I don't like a flap, I leave it there and then when cutting I just cut it off. I guess that may be inconvenient if you have a cutting machine. I guess we could have a new mechanism when in "Tab mode" that hides it, maybe by holding the "shift" key? The "shift" key already does something special in "Face mode" and in "Edge mode", but not in "Tab mode".

That sounds good. Or single click could just cycle swap flap -> remove flap -> flap on original. But I like shift better, this is rare, and you would have to add a timeframe after which the cycle reset, and/or any other action should reset it, so that you're never in the situation where you'd except the flap to be swapped, and it is instead removed.

As long as "modifier + click" actions are not that complicated (ie, they fit in the bottom line explanation) you don't need anything fancy. I could imagine a context sensitive right click command menu instead, but I don't think it complex enough yet to need that.

5. Removing/Hiding faces. Again, from Blender that is trivial. But having the unwanted faces all together with all the unwanted folds, and moving them out of the paper seems like a good enough solution. They are still shown in the 3D model, however.
   Yes, that works, that is why this is pretty down the list.

The problem with actually hiding them is: if you change your mind how do you get them back?

Either there's a toggle to show/hide let's call them "disabled" faces, or they could be rendered faded/transparent whatever. I think the toggle would work, it seems like a separate workflow step when you want to deal with it.

Some of these things could be solved by adding a menu to edit the "edge properties" separated for each edge, but I'm hesitant to add those. Currently all options are global, so "what you see is what there is" (WYSIWTI?), there is no hidden information anywhere. Adding per-edge options could mess that model. Imagine that you change your global tab-width and suddenly some tabs will not update because there is some option somewhere that overrides it. I guess that we could design a good UI around edge/face options, but I'm not sure how... Using color codes may not play nice with background textures.

Ah, yes, this is a very good point, and a lot of tools do make a terrible job of letting you chase down customizations. I think it must be something you don't do "by mistake", so yes, probably a context menu, and one that has a "reset to default" option. For finding those that are changed, I can imagine adding emphasis by highlighting them in bolder, some bright color. If this is a sort of overlay view that you can toggle, then you can even fade items that are default, and remove textures when rendering.

I could also imagine some floating icons that kind of transparently indicate these, but that might become cluttered.

And yes, this sounds like a lot of work and extra complexity and maybe better left to the modelling part. I think my brain tries to pull things here to be able to do updates in a single tool.

About helping with testing that will be great. Can you tell me what Operating System you are using? Also, are you able to build the version yourself or would you need testing builds (no problem either way)?

I'm on linux, specifically Fedora 38. I guess rustc or cargo or whatever is in the toolchain can't be worse than autotools, so I think I'll manage with a branch :)

I think I will prioritize items 2 and 4... stay tuned!

Great, thanks!

[kroozo]

I'm on linux, specifically Fedora 38. I guess rustc or cargo or whatever is in the toolchain can't be worse than autotools, so I think I'll manage with a branch :)

Of course there is some chasing around C devel packages, but I've just tested 6107a3f and it seems to work great!

[rodrigorc]

Hi @kroozo!

I have just pushed a commit that implements the "Print edge ID" feature.
It is disabled by default, but can be enabled from "Document properties / Page layout / Edge id font size".

For now, it only prints the ids in the printable (SVG, PDF or PNG) file, no feedback in the GUI.

I've reworked the SVG output in particular, so that the text is in its own layer now, so you can move the ids around if you don't like the default positioning.

Can you test it and tell me what you think?

[kroozo]

Hi,

I have done some testing, it looks pretty good already. Looks, and aligns good, the separate layer in the svg is pretty good.

There's one important thing: I have assumed the IDs to be printed inside, as that's what I've always seen, and because I'd expect them to be there when I'm gluing, not on the scrap paper. Of course now that I think about it I get that if there's texture, you would not want that to be printed on top, and I assume there are people who do not want anything printed outside, hence the out and in segment options on folds, but I still think that this should at least be a setting. For me, it's much easier if its on the face, and I don't care, I'll paint it anyway, I can't glue without getting some grease on the model inevitably :)

There are some others, more on the idea/food for thought side.

1. There might be some issues at overlapping with short edges, this for example is two zeroes:
   but this would also have a problem, if it was inside (and was maybe longer):
   
   I'm not sure if it worth trying to fix it automatically through, its rarely an issue in reality (it has to be short and it has to be the only one that connects the two pieces, otherwise you'll just look for a neighbor), and even then is pretty minor.
2. Also, I think if there's no texture, then maybe the background should be a below the text layer, so you don't cover up the label with a white box.
3. I think rim IDs shouldn't be printed, so you don't go chasing around the other side
4. The same applies to edges with hidden flaps?
5. It would be a nice added bonus if the edge numbers where somewhat ordered (and maybe without gaps) along maybe consecutive edges. I have had quite a few "what comes here, where the ... is 942" on papekura genererated pdfs. This might help, through probably is not the real solution to that problem. I do understand that this is a different angle that how you probably generate the IDs now, and there is going to be seemingly random numbers on some pieces no matter what.
6. Orientation indicators could also be helpful in some circumstances. I also remember having some issues identifying which way the number is up when you're half glued already. For example this:
   
   wouldn't be immediately obvious if it's 89 or 68, especially if you don't see the others (or they are at a sharper angle), the usual way is to underline the ones that only have 6, 8 or 9 digits in them.
7. I'd also prefer the IDs to be of uniform length, so you immediately see if an overlap hides some of it, but this is very very minor. (It would also get rid of ID 0, which is strange for "normal" people.

Great work!

[rodrigorc]

I have assumed the IDs to be printed inside, as that's what I've always seen [...] if there's texture [...]

0. Yes, the numbers will ruin a printed texture. In my workflow I prefer to have them outside the model, and in case they overlap other pieces they should go below.
   But if you are going to paint it, it makes much more sense to print them inside. Let's add an option for that.

About your other points:

1. Overlaps. That is a hard problem in general, and I don't think it is worth it. There could be some minor improvements, for example, now in a triangular flap I'm adding the number to the longer of the two sides, instead of to the first one. Instead of trying to solve this automatically (and probably failing) I think it is just best to leave it as-is, and if the user really cares about it, they can open the SVG in Inkscape and move the numbers manually.
2. Above or below. I think that the right thing to do would be:
   • If the user chooses "outside", then they probably care about the texture so the text goes below.
   • If the user chooses "inside", then the text must go above, no matter the texture.
3. Rims. Right, rims should not have IDs.
4. Hidden flaps. I'm not sure about this. A hidden flap still has a companion, I don't know why the user decided to not have a flap, maybe they plan to staple it... And the numbers are still useful for reference, as the matching sides go together in 3D space. Also, you could choose "No Tabs" in the "Model configuration" and I don't think this should disable the numbers either.
5. Order of numbers. Currently I'm using the internal ID of the edge, that is somewhat arbitrary. And all hidden edges (those generated for N-gons by tessellation) also have IDs but are never shown. That is easily improved, although I would like to use "stable ids", meaning that joined faces will also have an ID that will be hidden, so that the numbers won't change when you join/split some pieces. There will still be gaps, but much smaller. About the order of the numbers... I'm not sure, maybe ordering by Z-coordinate gives something meaningful?
6. Orientation indicator. I thought that you could just look at the next number and deduce the orientation. But you are right, if you are cutting and gluing, the pieces are all entangled and it may not be obvious. But I'm not a fan of the underscore, there are already many lines in the paper, and underscores can make it worse in some cases. I've seen a dot used for this: "89." vs "68." somewhere, let's see how it works.
7. Uniform length. But that would imply adding left-zeroes or a rectangle or something like that. When/If the IDs are shown in the GUI then overlaps should be more obvious. The ID=0 is silly, of course, but that is fixed with point 5.

I've pushed a few commits that implement points 0, 2, 3, part of 5, and 6, and fixed a few bugs. Can you check it and tell me what you think? I really appreciate the feedback!

[kroozo]

Hi,

Took a look.

0. Looks good. I actually like that they are on the flaps on the flap side quite a lot.
1. Yes, I agree.
2. Yes, with this new option this is the way.
3. 👍 (And works)
4. Yeah, I was unsure as well, I haven't thought of strapling
5. I figured that its some intrenals. I am not so sure about the need for stable IDs through. It's tempting, but in reality the whole "printable" seems like a unit. Well except if you're just fixing up an error somewhere, and need a few new faces, that's true. Ah, this bottom->top, back->front, left->right is actually quite ok. It does have a tendency of alternating consecutive numbers on the sides of a face that goes upwards in space, that's a bit strange at first. But if one understands this it probably is helpful, you can know if this thing goes above or beyond. I guess this is something that one can really see when sitting down with a more complex model and paper and glue :) (I had an idea on this whole where does it go problem, i'll try to draw a sketch, that's maybe even better than face IDs. )
6. I agree, the dots look nicer. This is better than not having them, in reality it irks me a bit that they are everywhere, where they are redundant, not just where the number is problematic. I can't give a solid reasoned explanation, it just feels ... off when I look at the output.
7. I was thinking of simply dumping them into the next x10 range (ie, up to ~100 its 10..99, then 100..999). But it probably doesn't worth the hassle at all. It already looks good.

[rodrigorc]

About the dots, yes it looked a bit weird at first, but I think it is growing on me. It works both as an orientation indicator and as a separator:

Also it can work as a sign of identity, you see a model with dots and you know what tool they used 😋 .

About the stable IDs, it is not critical, but frequently when cutting models I mess a few pieces. Then I go back to Papercraft, move all the failing pieces to one page, fix some hard cuts/joins if needed and reprint just that page. Having the same IDs here is a plus for me. Also I'm thinking that those IDs will be useful if/when I implement the "edge properties" tool, to keep track of what the user is doing.

[kroozo]

So, my mind took a step back somewhere on thinking on 5, and I started asking the "why" questions. I think it boils down to "Which is the next piece, and where do I align it". In this sense, a) I don't care for the actual IDs at all, they are just pairs I'm trying to find. b) a lot of them is insignificant, you'll look the the two ends of a long edge, pick one, and start gluing the flaps on the piece one by one till the end. You don't care about IDs in the middle.

So I thought, what if we indicate what is significant. My rough idea is:

1. Give faces and ID (number)
2. On the edge (in the corner) indicate the first and last point of a consecutive segment , with the face id that comes there
3. Preferably with different symbols. I though of some triangle arrow, maybe like this: "13ᐅ ... ᐊ13", probably one of them filled, or something of the hundreds of unicode arrows

Here is a hastily drawn ugly example of a diamond, with red arrows for the start and blue for the end.

Basically you look for the next piece, you read the number, pick that one up from the pile, you align the start mark, and you know what to do.

As an added bonus, if the user numbers the faces, you can indicate intended assembly order.

[rodrigorc]

Those arrows are fancy! In SVG it would be relatively easy, but what about a PDF/PNG? I would need to draw the arrows myself, and that would require some thought. If you have long strips of edges joining the same two pieces that is nice, but if the edges switch pieces a lot, it could be a mess of arrows.

I had thought about giving pieces an id too, and then tagging the flaps with "pieceid-flapid". So in your diamond, the "22" becomes "1-22." in piece 4, and "4-22." in piece 1. One drawback is that the tags are different on each side of the cut. Maybe naming the pieces with letters would be more pleasant: in piece A: "B-22.", and in piece B "A-22.". Another drawback is that piece names will not be stable, because each time you join/split pieces you will have to recompute them somehow.

I thought also of drawing spline lines connecting the sides of a cut, going below the pieces... but what if they are on different pages? I thought of the lines going out of one page and into the other, depending on how you have the pages layout in the GUI. But then, for big models it might look like a crazy mess of lines.

[kroozo]

Those arrows are fancy! In SVG it would be relatively easy, but what about a PDF/PNG? I would need to draw the arrows myself, and that would require some thought

Oh, those are just for demonstration, this was easy with the annotation tool in gwenview. I definitely would go for a text char in the label. There's quite a lot of utf arrows, and then it's just a good font that has them, but you could even just go with ">" and "<". So like 123> [edges here] <123. But since really its just the position the marker, you could use the same char, even the dot that is already there like 123. [edges here] .123. And you can also choose to mark the outside instead of the inside, for eg. with a pipe: |123 [edges here] 123|.

If you have long strips of edges joining the same two pieces that is nice, but if the edges switch pieces a lot, it could be a mess of arrows.

I don't think it will be too bad (I tried to do the diamond somewhat messy), but I have actually been overthinking it: I pushed them to the corner to to push to the actual start (and when drawing and zooming they look farter away than in reality), but actually, they could be at the center, right where the edge ID is currently, in reality having "123>" on an edge is just as good as if it was in the corner. And, for the single edge connections you don't need two, like in my example, you could just do ">123<", ".123.", or similar, or just omit the marks alltogether. So it's the same amount of labels, a bit longer.

I had thought about giving pieces an id too, and then tagging the flaps with "pieceid-flapid". So in your diamond, the "22" becomes "1-22." in piece 4, and "4-22." in piece 1.

I think that works instead of the marks, too. It's like the dots a bit: most of the time, it's just noise, and it misses a clear mark of direction, but on the pro side the sideid can be stable, that helps followups when fixing thing.

One drawback is that the tags are different on each side of the cut.

I have been thinking of that too, but I think the process goes that "what comes next, okay, I will need piece 4, i pick that up, and find the edge I need to start by the faceid backreference on that. But yes, if the edgeid is in there too, then that helps identify the edge.

As an alternative you could mark them with both face IDs, so if you connect face 1 to 4, then it becomes 1-4 on both sides (well, "1-4>"). (Or, you could go 1-4 and 4-1, the actual pieces always being on front, and then you wont have to find a place for the face id, if you print outside, ie, you don't want to print on the face)

I can imagine a few odd scenarios where you connect 2 pieces with two separate segments, but that should give itself quite straightforward during assembly.

Maybe naming the pieces with letters would be more pleasant: in piece A: "B-22.", and in piece B "A-22.".

I was thinking about that, but you'll hit AA, AB pretty soon.

Another drawback is that piece names will not be stable, because each time you join/split pieces you will have to recompute them somehow.

Yes, I had that in mind as well, it sounds a bit tricky. If it's automatic, I think you can maybe sort by size (as in, number of faces), with a preference to keep the old ID if there are equal sizes. That should not mess with the IDs of already existing islands too much when working with them. If there is user control... that's trickier.

One other thing I'm not sure about is self connecting pieces.

I thought also of drawing spline lines connecting the sides of a cut, going below the pieces... but what if they are on different pages? I thought of the lines going out of one page and into the other, depending on how you have the pages layout in the GUI. But then, for big models it might look like a crazy mess of lines.

Ah, that sounds fancy, not sure how to do that nicely.

[rodrigorc]

I think the priority here is not to make it too complicated. Users seldom read the documentation, and imagine those models that are printed and sold in a street market, or in Etsy or wherever... the end user will have no idea what all those little wiggles mean.

That said, I pushed a couple of experimental branches:

• island_id: The pieces are named with letters, and the edge ids are prefixed with the other piece name.
• edge_id_range: Edge strips that glue to the same piece are enclosed in angle brackets <>.

If you have time, could you check them and tell me what you think?

[kroozo]

I think the priority here is not to make it too complicated. Users seldom read the documentation, and imagine those models that are printed and sold in a street market, or in Etsy or wherever... the end user will have no idea what all those little wiggles mean.

Yes, I was actually aiming to come up with something less complicated from a users perspective. But I give you that understanding just IDs is easier.

I played a little bit, thought it would be good to look at a more real world example, so I grabbed a chicken: https://poly.pizza/m/1YE8U35HXsI, and assembled some islands, to see how the output feels.

The edge_id_range does not seem to add much help. It helps identifying that something starts here, but search is still needle in a haystack. And yes, it does look cryptic.

The island_id is much much better. It seems like an immerse help to identify what to look for. It will also be quite straightforward to find the info that the other denotes with brackets. The only thing that might not be instantly obvious is that A-123 and B-123 go together, but once you saw a single example (and you will, at an obvious piece you start with) it will be straightforward. I think this is a good way to go.

Some observations on details:

• I think you can go leave the dash, if faces are letters, it'd be readable without, and shorter
• Still, smaller parts end up quite messy:
  
  
  I've checked with 4pt fonts, it's better (but is on the edge of readability when printed), I think 8pt is too big for the default value, but I'm still kinda thinking on hiding "not that important" labels, or I'd revisit the idea of trying to do a better alignment when generating
• The center is not the best place for the piece label for concave shapes:
  
  
  Maybe center of mass, or center of largest face is a better strategy.
• When the labels are inside, the text is written on the flap's cut line. Especially if the flap is short, it might be better to write it on its fold line instead:
  
  This was much more obvious with the smaller font.

---

Working on a complex model was a pretty fluid experience, I really like how once I caught up a start point I could literally get something meaningful done in maybe 10 minutes. I ended up mostly working on the right side, pulling up the pieces one by one to form meaningful islands. I did find myself sweeping around the edges of island quite a lot, to see if there are / where are new pieces, not edges to already existing islands. It may be helpful to be able to briefly show all connections of an island.

[kroozo]

Remove the dash. I think some separator is needed. If I see "A123" I will tend to look for another edge labelled the same "A123", but "X123" will look to different. Also the "011" and the "I10" would look kind of similar. I think a colon looks nice and is shorter than a dash: "A:123". With this I think the ending dot is no longer needed, the letter and colon mark the way. There is still some theoretical partial ambiguity but I think they are not worth it ("I:1" upside down is still "I:1"!).

You are right, I've clearly have not given this enough thought. And the colon is very good choice. Shorter, and actually conveys the meaning better, at least to me. 👍

Mess in small tabs. You are right, if the id inside a flap is next to the fold line instead of next to the cut line, there is more room. So done! That helps a bit with the mess, particularly with triangular tabs. And they will be all parallel. I could move them inside the model itself, but that could make things worse, depending on the model. This has the nice side-effect that when the ids are outside, in a triangular flap, they are now parallel, too.

Looks pretty good. I still did find a few places cramped, but its gonna be much less frequent. From what I seen, on thing that might be worth trying is rotating the label 90 degrees if it is longer than the edge (Face probably have to be that big to fit the label in one direction, and even if not, it's probably better to overlap with something inside)

Also, maybe 1-2 extra pixel padding from the line would help readability, especially once you folded the flap.

Position of the piece label. Indeed, I was using the center of the bounding box when inside, and the top of the bounding box when outside. Not very nice. I have changed to:
When outside, just at the top of the highest vertex.
When inside, in the center of mass of the biggest flat-face (flat-face are the faces before tessellation).
Naturally, the biggest flat-face may also be concave, but it should be much less noticeable.

Seems perfect.

Also I sorted the piece IDs by number of faces (after tessellation), so the piece with the most faces will be the "A" and that with fewest will be the "ZZ". This makes it easier to navigate the model, but also means that longer IDs are in potentially smaller pieces. It could be changed to "pieces by area" or "pieces by flat-faces" or "by page", but I don't think it matters too much.

Not really, not with the edge IDs being separate things. The by-page (and maybe some xy order on that) gives some ordering possibility in the hand of the user (although very crude), and most of the times you'll probably put thing that come after each other somewhere near.

I'm quite happy with the looks of it 😎.

Cool indeed. 😎

That can be a useful tool, maybe holding "Alt"? But I don't know how easy it would be. Would you mind opening a separate issue for this?

Sure, opened #8 .

[rodrigorc]

maybe 1-2 extra pixel padding from the line would help readability, especially once you folded the flap.
Not pixels, everything is measured in millimeters. The separation from the line is proportional to the font size, that's probably why your smaller font got all cramped.
Anyway I think you are right, it is too near, I've added a bit of extra separation.

I think this issue is mostly done and can be closed, do you agree?