Forum Replies Created

Viewing 7 posts - 4,321 through 4,327 (of 4,327 total)
  • Author
    Posts
  • #41368

    The complete silence around this problem worries me.

    Since our customers have problems, and you don’t seem to take this problem seriously. could you perhaps recommend an alternative to PD4ML?

    Best regards,
    Palle

    #41369

    Hi, Palle! We apologize for the communication issues you’ve experienced. Did you not receive a response regarding ticket HELPD-848? We are working on resolving this; a fix is ​​scheduled for the upcoming build, which is due out in about a week.

    #41370

    I didn’t get a response, but I’m happy to hear you’re adressing this. 🙂

    Thanks,
    Palle

    #41483

    I see the new 4.1.1-SNAPSHOT.zip and 4.0.23fx1.xip. Do they both have a suggested fix for this problem? Which one would you recommend for production use? Also, if we need a jakarta version, how do we go about getting that?

    Best regards,
    Palle Girgensohn

    #41484

    Hi! The issue was initially resolved in version v4.0.23fx1, and the fix was subsequently ported to version v4.1.1-SNAPSHOT.

    v4.0.23fx1 is currently in “released” state, so it is recommended for production. v4.1.1 is going to be released only in 7-10 days.

    Both version should switch automatically between jakarta and javax depending on runtime environment.

    #41486

    Thanks, it seems to be working fine. When it comes to jakarta, we’re using tiles so we also nedd version 3. Does that jar have the same automatic runtime detection of jakarta/javax?

    Palle

    in reply to: Technical questions / Troubleshooting
    #41584

    Hello PD4ML Support Team,

    We’ve identified a rendering defect that is reproducible across multiple PD4ML v4 builds, including our current version. We’d appreciate your review.

    PD4ML Versions Tested (issue reproduces identically on both):
    – 4.0.21-20240926-0231
    – 4.0.23fx2-20260908-0058

    Issue Summary:
    When an element has border-radius, a background (solid color or linear-gradient), a partial border (e.g. border-bottom only), and overflow:hidden applied together, the border-radius and border render correctly, but the background does NOT paint at all. The element renders with a transparent/white interior instead of the specified background color or gradient.

    We have confirmed this is specific to the background property — border-radius clipping and border rendering both work correctly in isolation and in combination with each other; only the background fails when combined with them.

    CSS (unmodified, as shipped):

    .experience-card-poor {
    border-radius: 14px;
    background: linear-gradient(
    to bottom,
    #FEF7F8 48%,
    #FFFFFF 100%
    );
    border-bottom: 4px solid #EE223B;
    overflow: hidden;
    }

    HTML:

    <td width=”33.33%” style=”height:121px;margin:0px 10px 0px 0px” class=”experience-card-poor”>

    Poor
    <span>35</span><span class=”f14-normal”>%</span>
    3309

    </td>

    We also tested with a plain background-color instead of the gradient, and the result is identical — the issue is not specific to gradients, it affects background painting generally under this combination of properties.

    Expected result: card renders with a rounded top, the specified background fill, and a colored bottom border (see attached reference/expected mockup).

    Actual result: card renders with correct rounded corners and correct colored bottom border, but no background fill at all (see attached PDF output / screenshot).

    Could you confirm whether this is a known issue, and if so, whether a fix is planned or already available in a later build?

    Happy to provide the full HTML/CSS source, additional screenshots, or a minimal standalone reproduction file if useful.

    Thank you,
    Dhanabal.V

Viewing 7 posts - 4,321 through 4,327 (of 4,327 total)