Can vspace take negative len?

#1 
<\with|par-par-sep|0fn>
  aaa<vspace|-1fn>
  bbb
</with>

The effect of this is as if vspace takes the argument of 0fn. I need to make aaa and bbb more compact.

#2

I looked into the manual and I tried it and I did not find that it can.

You can move words upwards using the shift primitive, but perhaps this is not the method you are looking for.

#3

Yeah, shift does part of the work.
image

But the position of ccc, which is after bbb, is fixed. I need it to move upwards as well.
image

#4

I think that happens because shift does not move the bounding box. The primitive move does move it, but I could not get it to make bbb close to aaa. I do not know if that is intended (perhaps boxes must not collide) or a bug. Sorry that I cannot help more.

#5

Thank you for putting the effort! I don’t know if the dev’s are here. I think supporting negative vspace can increase the flexibility of the typesetting of texmacs.

In some scenario, this feature is essential. Because the gap between two consecutive paragraphs can just be too big, even with par-par-sep=0.

#6

What about this:

<\with|par-sep|-1fn|par-par-sep|0fn>
  fsdfdsfdfsdfds

  sddasdasdasd
</with>

or

<\with|par-sep|-1fn|par-par-sep|0fn>
  fsdfdsfdfsdfds

  <reduce-by|sddasdasdasd|0.8ex>
</with>
#7

A little more compact. But the limit is obvious, can’t overlap. I imagine the kind of flexibility that allows us to overlap two paragraphs.

#8

It may be that the C++ code needs to be changed. IMO this is a good issue for the bug tracker at Savannah, to be filed under the wishlist category .

1 Like
#9

https://savannah.gnu.org/bugs/index.php?66852

Done. First time to know this is where the devs are hosting bugs.

2 Likes
#10

I’m not sure I can. What is that are you really trying to achieve? Can you explain a bit your use-case, so that we can understand what is the best way to support it?

#11

image
image.png908×809 34.8 KB

I want the vertical whitespaces around the horizontal bar to be smaller.

#12

In TeX the vertical placement with vspace seems free. I have obtained this

image

with the code

abcd

\vspace{-1em}

cdef

ghij

Freedom of placement would support all use-cases and I do not see disadvantages.

1 Like
#13

Well, it depends what you mean. If we start to copy blindly all the LaTeX/TeX features, we will slowly build up our own issues + the TeX issues. In this case while the solution seems very easy, it would mean to implement something that maybe cannot be reliably exported in HTML (for example), limiting the usefulness of the construction. I agree that there seems to be a limitation now, but the proper way to support what the user requires it is still not clear to me. I need to experiment with their specific use case to see why with the current markup we cannot describe the needed layout. In this specific use case we need just to convince TeXmacs not to put additional space around the \hrule, not to superperpose boxes (which can already be obtained with other primitives).

1 Like
#14

I see. This was outside what I was able to see, thanks for the explanation (also in the wider sense of looking beyond the immediate).

#15

image
This is the html rendered from source (vue + tailwind):

    <button type="button" v-on:click="show = !show">{{ show ? 'Hide' : 'Show' }}</button><br>
    <transition enter-active-class="animate__animated animate__bounce"
      leave-active-class="animate__animated animate__bounceOutRight">
      <div v-if="show" class="text-4xl border inline-block">
        Hello world!
      </div>
    </transition>
    <div class="-m-20"></div>
    <div>
      <h3>Screen Resolution:</h3>
      <p>{{ screenWidth }} x {{ screenHeight }} pixels</p>
    </div>

Notice the negative space here: <div class="-m-20"></div>.

Html doesn’t stop one from using negative spacing. It seems html compatibility is achievable. Of course, the feature may not be critical to most users. I don’t judge the judgement on the priority. Just saying this seems to be achievable.