Site update: Fixes for styling (text color) and custom layouts

While I do not write one of these each time we roll out new changes in production, I felt it was worthwhile to mention this update since it addresses some issues that have been with us ever since the v4 release, and that so far have been stubbornly refused to go away:

Styling / text color issues in certain browsers/platforms

We’ve had various issues with the intricate interplay between the Docusaurus, TailwindCSS, and DaisyUI CSS rules.

These issues were always tricky to troubleshoot. For one thing, they often would not appear when running the site in development mode, but only in production. But even in production, it was often hard or impossible to reproduce these (since we do not have access to every browser/platform).

As such, part of me is reluctant to proclaim the matter as resolved. However, I have reason to be optimistic. Not only we run a test with several users who previously experienced issues, and they all confirmed that the latest changes resolved their issues.

But there’s also the nature of the fix. We’ve completely replaced the CSS-minifier library we use as it was in the build/minify step that the problem was introduced (hence why it does not happen in development mode).

Obviously, let us know if you notice anything that seems off, but I’m cautiously optimistic about this one :crossed_fingers:

Custom layout crashes and bugs

The custom layout page had issues open for causing page crashes, as well as not taking the layout into account (which manifested in parts snapping back to their original location after dragging them.

Here we’ve made changes too, and so far we’ve been unable to reproduce any of these issues.
In the process, we also removed the Apply Layout button. Instead, the layout will be applied automatically for every change you make.

The button was originally added because there’s a rather complex under-the-hood dance happening between the layout that is kept in the UI state, and the layout that is passed to the FreeSewing Core library to draft the pattern.

However, it’s not the kind of thing the casual user should be concerned with, so we’ve removed the button and will now apply the layout on every change. Because that’s probably what you want anyway, right?

Thanks for your patience as we continue to make things better :innocent:

4 Likes

After this most recent update, every paper size downloads as a letter sized PDF for Charlies Chinos. The patterns layout for each size differ, but the meta size of the pdf’s remain letter sized. This issue persists on both linux Firefox and Windows explorer and chrome. Also the pattern’s paper size wont keep when you change it in the “Pattern Layout”, it snaps back as soon as any other change is made, part is moved etc.

2 Likes

I am able to reproduce both of these issues on Mac desktop Safari.

  1. Exported PDFs appear to generate with pattern layouts at the correct paper size, but when you inspect the PDF document metadata you see that the paper size is always 8.5"x11".
  2. In Layout view, the page size reverts back to default A4 (I have metric preferences set) whenever a part is moved.

Regarding issue #1, I caused the problem via my PR #458 when I changed the variable name from size to pdfkitSize. I didn’t catch the issue when testing the PR because the PDF layouts looked correct and I didn’t see that the paper size was wrong.

Edit: I filed PR #467 to fix the issue.

1 Like

Thanks for letting us know @user-103811 :folded_hands:

@Benjamin_F fixed problem 1:

And I’ve fixed problem 2:

Both fixes have been deployed in production.

1 Like