Table align y not working

[AntoninD-Galadrim]

Bug Report

Table align doesn't seem to work vertically

Description of the problem

Code sample

(doc as any).table({
data: [
[
{
align: { y: 'bottom' },
backgroundColor: '#ccc',
text: 'test',
},
],
],
});

Your environment

pdfkit 0.17.1

[hollandjake]

Hi @AntoninD-Galadrim, since there is no other content on the row and the row is dynamically sized (since you haven't specified the height), it means that the height is the smallest it can be hence the alignY does nothing in this case.

If you enable table({debug: true, ...}) you will see where the bounds of your text is.

What you are likely looking at is a result of either the fonts baseline being wrong, or you have modified the text baseline.

If you are still seeing this, can you send a screenshot with debug enabled

[hollandjake]

For reference here is what your example code generates (with debug enabled for clarity)

[AntoninD-Galadrim]

@hollandjake

  const doc = new PDFDocument();
  (doc as any).table({
    debug: true,
    data: [
      [
        {
          align: { y: 'bottom' },
          text: 'test',
        },
      ],
    ],
  });
  doc.end();

This is what I get on my end, default font and everything.

[hollandjake]

Thank you for that, managed to replicate too. Investigating, it seems that the calculation for how high a line is, is always factoring in the lineGap despite that line being the last line in the string. This replicated the same behaviour as the heightOfString method. @blikblum thoughts on whether this is correct behaviour?

For reference this also occurs in the doc.text method, moving the last lines y position to the next line including the gap.

If we don't want this behaviour and we want the last line to exclude the gap. with some tweaks to the lineWrapper, and the heightOfString function. we can get the following:

Where the height of the first textBox is computed with heightOfString you can see the line it cut, however the doc.y position is still including the gap so subsequent calls still use the gap. Code branch: https://github.com/hollandjake/pdfkit/tree/text-last-line-gap

[blikblum]

thoughts on whether this is correct behaviour?

At first look no.

Need to look for the possible behavior changes in other use cases.

[blikblum]

Assuming lineGap is the equivalent to line height is should be applied only between lines of text, description from google / AI:

Font line height, also known as "leading," is the vertical space between lines of text. It's a fundamental typographic practice, impacting readability and making text easier to scan and understand. Line height is set in CSS, either by a percentage of the font size or a fixed length unit.
Elaboration:

Measurement:
Line height is measured from the baseline of one line to the baseline of the next. 

Units:
It can be expressed in various units like pixels (px), em, rem, or as a percentage of the font size.

Impact on Readability:
Proper line height ensures enough space between lines, preventing text from looking dense and crowded, especially when using smaller fonts.

[blikblum]

Although the specs hints it applies only between text lines, in browser css it affects before and after text

https://developer.mozilla.org/en-US/play?id=arr45vJCgMKYeU1CksvmAB7uY9pKTMusgCGBNY5ZHI20jxBn9azXgmoDR9QaEgN9RhY3%2Brkx5EglCwRG

We should evaluate how other pdf libs, typesetting systems (typst), handle this

[hollandjake]

@blikblum findings so far:

• pdfmake:
  

• css:
  

• iterm:
  

• quest pdf:
  

if you want any more let me know.

if we want, we could preserve existing behaviour (including the trailing space) by putting it behind an option flag in the heightOfString / boundsOfString / table functions

[blikblum]

if we want, we could preserve existing behaviour (including the trailing space) by putting it behind an option flag in the heightOfString / boundsOfString / table functions

It is better. You can use this option in table and let current behavior in other places

[hollandjake]

@blikblum just been doing some more testing and I noticed that the trailing line gap issue is only occuring in the system fonts, using roboto it does not cause it. could this be a disparity between system font and the internal font?#

helvetica (system default):

roboto (custom font):

[hollandjake]

using the feature flag on a default system font, we can now achieve the following:

Use on a custom font does not seem to cause or break when using the flag

[blikblum]

could this be a disparity between system font and the internal font?

Good find

custom font uses fontkit, system font are handled internally

i will look at it ASAP

[AntoninD-Galadrim]

Thanks for the work everyone.
Any news/fixes on this ?

[AntoninD-Galadrim]

@blikblum Sorry for the ping, do you know if there is some fix or workaround ?