analytica-frontend-lib/dist/components/HtmlMathRenderer/utils.d.ts

Repositório público dos componentes utilizados nas plataformas da Analytica Ensino

/**
 * Utilities for processing HTML content with LaTeX math expressions
 */
export interface MathPart {
    type: 'text' | 'math' | 'block-math';
    content: string;
    latex?: string;
}
/**
 * Cleans LaTeX string from invisible characters and decodes HTML entities
 * that the editor saved in place of math operators.
 *
 * Why decode here: KaTeX is a LaTeX parser, not an HTML parser. If the
 * source has `<`/`>` (because the editor HTML-escaped them on save)
 * KaTeX throws "Expected 'EOF', got '&'". `<`/`>` map to the
 * equivalent `\lt`/`\gt` commands. `&` decodes back to a bare `&` \u2014
 * NOT `\&` \u2014 because in LaTeX `&` is the alignment character (used by
 * `\begin{align}`, matrices, etc.); rewriting it to `\&` would break
 * alignment and stop already-escaped `\&` from round-tripping.
 */
export declare const cleanLatex: (str: string) => string;
/**
 * Heuristic that flags a string as "likely real LaTeX math" vs prose.
 * Used to reject `$...$` blocks that wrap regular text \u2014 typically
 * happens when authors type `$` as a currency symbol and the renderer
 * pairs unrelated occurrences as math delimiters, sending Portuguese
 * prose to KaTeX (which then renders each letter as a math variable).
 *
 * Approach:
 * - Backslash commands / sub-super / grouping braces \u2192 definitely math.
 * - Otherwise, treat it as PROSE only when it contains 2+ real words
 *   (runs of 3+ letters). A sentence like "15,00 pelo custo fixo" has
 *   many such words; genuine math \u2014 `x = 1`, `a + b`, `1 < 2`, `f0`,
 *   even a lone `abc` \u2014 does not. This keeps normal spaced equations
 *   rendering while still rejecting currency-`$` prose.
 */
export declare const looksLikeLatex: (str: string) => boolean;
/**
 * Heuristic that decides whether `content` is Markdown (as opposed to the
 * HTML the backoffice RichEditor produces). AI-generated questions and
 * resolutions arrive as Markdown + LaTeX (`**bold**`, `#### heading`,
 * `* lists`, `$...$`, `$$...$$`), whereas the editor stores HTML (`<p>`,
 * `<b>`, `<span class="math-formula" data-latex="...">`). The two sources are
 * cleanly separable, so we bias toward the proven HTML path:
 *
 * - If any real HTML element tag is present we return `false` and let
 *   `HtmlMathRenderer` handle it exactly as before (math-formula spans,
 *   currency heuristic, katex-error recovery, sanitization).
 * - Otherwise we return `true` only when an unmistakable Markdown marker is
 *   present (ATX heading, bold, bullet/ordered list, GFM table, or a paragraph
 *   break), which is what breaks today: Markdown rendered as HTML shows the raw
 *   `**`/`####`/`*` tokens and collapses line breaks.
 *
 * Regex note: line-anchored signals use the `m` flag with `^` and restrict
 * horizontal whitespace to `[ \t]` (never `\s`, which also matches `\n`). This
 * keeps each quantifier on a single line and avoids the super-linear
 * backtracking that `(?:^|\n)\s*…\s+` can trigger across newlines.
 */
export declare const isLikelyMarkdown: (content: string) => boolean;
/**
 * Sanitizes HTML content for safe display
 * Removes event handlers, dangerous attributes, script/style tags, and javascript: URIs
 */
export declare const sanitizeHtmlForDisplay: (htmlContent: string) => string;
/**
 * Processes HTML content and extracts math expressions
 * Returns an array of parts (text and math) for rendering
 */
export declare const processHtmlWithMath: (htmlContent: string) => MathPart[];
/**
 * Checks if content contains any math expressions
 */
export declare const containsMath: (content: string) => boolean;
/**
 * Extracts plain text from HTML content (removes all tags and LaTeX notation)
 */
export declare const stripHtml: (htmlContent: string) => string;
//# sourceMappingURL=utils.d.ts.map