I have tried 1st, 2nd points are working good just have to solve 3rd issue:
1. Title with bold: "THIS IS MY MAIN TITLE IN CAPS" (title not always same)
2. Words with bold: TEST ABC:, TEST XYZ:, TES T TEST:, TESTXXX: (this words are always same)
3. Some strings are not showing skipping a line when you run this code (lessthen and graterthen in string forex: <140/90 mmHg OR <130/80 mmHg).

<?php
$data = 'THE CORRECT ANSWER IS C.
<p>Choice A Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industrys standard dummy text ever since the 1500s</p>
<p></p>
<p>Choice B Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industrys standard dummy text ever since the 1500s</p>
<p>Choice D Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industrys standard dummy text ever since the 1500s</p>
<p></p>
<p>Choice E simply dummy text of the printing and typesetting industry.</p>
<p></p>
<p><br>THIS IS MY MAIN TITLE IN CAPS<br>This my sub title.</p>
<p><br>TEST ABC: Lorem Ipsum is simply dummy text of the printing and typesetting industry.</p>
<p>1) It is a long established fact <140/90 mmHg OR <130/80 mmHg making it look like readable English will uncover many web sites still in their infancy. 
<br><br>2) There are many variations of passages of Lorem Ipsum available. </p>
<p><br>TEST XYZ: Lorem Ipsum has been the industrys standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.</p>
<p><br>TES T TEST: It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.</p>
<p><br>TESTXXX: It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.</p>';

$dom = new DOMDocument();
@$dom->loadHTML($data, LIBXML_HTML_NODEFDTD);
$xpath = new DOMXPath($dom);
foreach ($xpath->query('//text()') as $node) {
    $txt = trim($node->nodeValue);
    $p   = $node->parentNode;
    if (preg_match("/^\s*(TEST ABC:|TEST XYZ:|TES T TEST:|TESTXXX)(.*)$/s", $node->nodeValue, $matches)) {
        // Put Choice X in bold:
        $p->insertBefore($dom->createElement('strong', $matches[1]), $node);
        $node->nodeValue = " " . trim($matches[2]);
    } else if (strtoupper($txt) === $txt && $txt !== '') {
        // Put header in bold
        $p->insertBefore($dom->createElement('strong', $txt), $node);
        $node->nodeValue = "";
    }
}
$data = $dom->saveHTML();
echo $data;

Dani AI

Generated

Short summary: the DOM truncation is caused by literal < characters in text being treated as the start of an HTML tag, so fragments like <140/90 mmHg are eaten when DOMDocument::loadHTML() parses the string. already pointed out the parser/encoding angle; the pragmatic fix is to make those less‑than signs safe before parsing (or use an HTML5‑tolerant parser if the input is very broken). The rest of the DOM-based manipulation (finding uppercase headers and fixed labels) can remain unchanged once the input isn't being mangled.

A minimal, safe pattern to apply before calling loadHTML() is: selectively encode < that are not the start of a real tag, then parse and use DOM methods that create text nodes (so special characters are correctly escaped on output). Example helper (illustrative only — adapt to the actual flow in the thread):

<?php
libxml_use_internal_errors(true);

// selective encode: only replace '<' that is NOT followed by a letter, slash or '!' (so real tags are preserved)
$data = preg_replace('/<(?=[^A-Za-z\/!])/', '&lt;', $data);

// force DOM to treat UTF-8 correctly
$dom = new DOMDocument();
$dom->loadHTML('<?xml encoding="utf-8" ?>' . $data);

// safe insertion example
function insertStrong(DOMDocument $dom, DOMNode $refNode, $label) {
    $s = $dom->createElement('strong');
    $s->appendChild($dom->createTextNode($label)); // ensures proper escaping
    $refNode->parentNode->insertBefore($s, $refNode);
}
?>

Extra tips: prefer libxml_use_internal_errors(true) over @ to see parse warnings; use mb_* functions when checking uppercase (e.g. mb_strtoupper(..., 'UTF-8')) so non‑ASCII text behaves correctly; avoid double‑encoding (detect if input already contains entities); and, as suggested, store and serve text with a consistent UTF‑8 pipeline (DB, PHP, HTTP) so encoding problems are avoided at the source. If the content can be very malformed, consider an HTML5 library (parser/tidy) that is more forgiving than DOMDocument.

Hi,

it happens because in <140/90 mmHg OR <130/80 mmHg) there is the < character that has a special meaning in the HTML parsing. Example:

<?php

$html = '<p>Hello < 140 / 32 World</p>';
$dom  = new DomDocument();
$dom->loadHTML($html);

print $dom->saveHTML();

It returns <p>Hello </p> (I've stripped the rest of the HTML).

To solve you could strip all the tags, or replace them with placeholders, see for example, convert to HTML entities all the special characters and then inject them back in the page.

But it's not worth if this has to be done frequently. In my opinion you should:

  • save questions and answers into a database;
  • apply an encoding (UTF-8 for example) to these strings: in the database, in the server so that requests and responses are treated the same, and in the HTML page, so that the browser will display them correctly;
  • use a template to generate the pages: so that you have to change only one file;
  • use approriate tags: titles and lists instead of paragraphs everywhere;
  • use external styles to change the appearance of the elements

or, if semantically relevant, you could just modify the template to add tags like strong, but operate on a template instead of altering multiple static files.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.