You are converting an ORIGINAL PDF FORM into a complete production-ready single PHP page for the Tuvigram website. Treat the ORIGINAL PDF as the primary source of truth. First inspect every PDF page visually, count all source pages, read every heading, paragraph, numbered point, declaration, affidavit, verification, order, rule, fee, signature area, witness section, officer section, photo box, table, document list and note. Never trust OCR blindly. If OCR text conflicts with the visible PDF, the visible PDF wins. Do not guess unclear government wording. If one important word is genuinely unreadable, ask only for that specific word or line. Recreate every original printable page using real HTML, CSS and Unicode text. Never use the PDF, screenshot, full-page image, iframe, canvas rendering or PDF background as the printable form. Main form text must remain real selectable, searchable and sharp Unicode text. Each source PDF page must become one separate A4 page using 210mm × 297mm dimensions. Preserve the original wording, meaning, numbering, government designation, Act name, Section number, Rule number, fee, declaration, verification, witness statement, officer text and signature labels exactly as visible in the source PDF. Do not rewrite official printed text for grammar improvement. Do not silently replace an old printed rule with a current rule. If current legal or government information is required, verify it only from official government sources and place it separately on an informational page without changing the original printable wording. No original line may be silently omitted. After coding, compare every source page again and verify that no heading, sentence, numbered point, signature line, witness line, officer line, mobile field, document requirement or declaration is missing. Preserve the existing Tuvigram website architecture. Support the file being located in public_html or public_html/offline-form. Use the existing /includes/bootstrap.php, /includes/header.php and /includes/footer.php architecture. Reuse existing functions such as e(), base_url(), db(), csrf_token() and csp_nonce() when available. Default deliverable must be one complete PHP file containing the required HTML, CSS and JavaScript. Do not unnecessarily rebuild existing working code. If an existing PHP file is provided, use it as the base and make surgical changes only. A small request must result in a small patch. Never remove or break working features such as persistence, crop, PDF, print, analytics, auto-fill, responsive layout, scroll behavior, SEO, header, footer or relationship logic. The website UI must be clean, light, professional and government-service inspired using white, grey, blue and subtle orange accents. Do not create a dark neon AI theme. If the form is related to Rajasthan, the interface may be visually inspired by Rajasthan government or Pehchan-style service portals, but never falsely present Tuvigram as an official government website. Keep the top area very compact. Use a small breadcrumb, small title, tiny description and compact action buttons so most of the desktop viewport is available for the form panel and preview. On desktop, use a two-column layout with a left dynamic form-filling panel and a right live A4 preview. Maintain three independent scrolling systems: normal browser/page scroll, independent left form-panel vertical scroll and independent right live-preview scroll. On mobile, keep the interface responsive, touch-friendly and usable, with the form panel and preview stacked when needed. Build a dynamic input panel by analyzing the PDF. Ask the user only for information actually needed to fill the form. Reuse the same input value everywhere it appears in the form instead of asking for duplicate information. Use meaningful keys such as applicant_name, father_name, mother_name, current_address, witness_1_name and similar keys instead of field1, field2 or random IDs. Use data-input for editable fields and data-bind for repeated printable values. Ensure every data-bind has a valid data source or generated value. Labels must be clear and contextual. Prefer labels such as Applicant Aadhaar Number, Applicant Jan Aadhaar Number, Applicant Mobile Number, Witness 1 Mobile Number and Witness 2 Mobile Number instead of ambiguous generic labels. Devanagari input text must never be clipped. Input fields must have enough font size, line-height, minimum height and top/bottom padding for Hindi matras such as ि, ी, ु, ू, ृ, े, ै, ो, ौ, ं and ँ. Use a suitable font stack such as "Noto Serif Devanagari","Nirmala UI","Mangal",serif. Long names and long addresses must wrap safely without clipping, hiding behind photo boxes or overflowing the A4 page. If applicant relationship logic is required by the form, create smart but editable relationship logic. Example: if the applicant is the father and the person is male, the printed relationship may need to become "son"; if female, "daughter"; if self, generate a grammatically correct self-reference. Only include relationship options relevant to the current PDF. Where useful, create structured address inputs such as village/city, post office, tehsil, district, state, PIN, current address, permanent address, event address or institution address. Add practical copy checkboxes such as Current address is the same as permanent address, Event-time address is the same as current address, Witness 1 address is the same as applicant address, Witness 2 address is the same as applicant address or Both witness addresses are the same, but only where they make sense for the current form. If structured address fields exist, a final full-address field may be automatically generated but must remain manually editable. If the original PDF contains photo boxes, create the required photo upload system for applicant, witnesses or other form-specific people. If the same applicant photo is needed on multiple pages, one upload must populate every relevant page. On photo upload, open a professional crop editor with mouse drag, touch drag, zoom, apply and cancel controls. Use a crop ratio matching the final photo box. The final cropped photo must fill the bordered box edge-to-edge using object-fit: cover without unwanted white gaps. Photo boxes must stay close to their original PDF position. Long text must not disappear behind photos. Use appropriate z-index handling instead of shifting the entire page unnecessarily. Persist user-entered values in browser localStorage. Refreshing the page must not erase text fields, textareas, selects, checkbox states and cropped photos where practical. Use a unique localStorage key for every different form so one form never overwrites another form's saved data. Provide a visible Clear Form button with confirmation. After confirmation, clear all text fields, selects, checkboxes, photos, crop data and localStorage data. Handle the current date intelligently. A fresh form may auto-fill today's date, but Clear Form must clear it. After clearing, an immediate refresh must not automatically reinsert the date. When a new form-filling session meaningfully begins, today's date may be restored. Always respect a date manually entered by the user. Use DD/MM/YYYY for Indian government forms unless the source PDF clearly requires another format. Numeric fields should use inputmode="numeric" where appropriate. Aadhaar should support 12 digits, mobile should support 10 digits and PIN should support 6 digits. Do not invent legal validation rules that are not supported by the current form or official requirements. If the user requests additional fields not present in the original PDF, such as Applicant Aadhaar Number, Applicant Jan Aadhaar Number or Applicant Mobile Number, add them clearly as additional fields without deleting or replacing original government wording. Fit those additions into available blank space and rebalance only the affected page. The live preview must update immediately when the user changes a field. No page reload should be required. All repeated instances must update automatically. Print/PDF must use the browser native print engine with real HTML/Unicode text. Do not convert the main page into a screenshot PDF. Main text must stay searchable, selectable, sharp and zoom-safe. If the live preview uses sticky positioning, overflow, transforms, viewport scaling or other screen-only behavior, do not print it directly. Before printing, create a clean print clone directly under the body, copy only the printable pages into it, remove screen transforms and use the clean clone for printing. Remove the clone after printing. Use @page { size: A4 portrait; margin: 0; }. In print mode hide the website header, website footer UI, left form panel, buttons, breadcrumb, crop modal, instructions, preview labels and all other non-print controls. Print only the A4 pages. Use page-break-after: always and break-after: page for every form page except the last one so no accidental blank final page appears. Provide separate action buttons for High Quality PDF and Print. On mobile also provide a Mobile PDF Download action where appropriate. PDF and Print may internally use the same native print engine, but analytics must track the user intention separately. Never claim JavaScript can reliably know whether the user selected a physical printer or Save as PDF inside the browser's native print dialog. Track only the initiating PDF/Print intent and print-dialog open/close events. At the bottom of every printable form page add a very small subtle footer: "This form was filled using Tuvigram Digital Form" or the approved Hindi equivalent, with "Tuvigram Digital Form" linking to base_url(). Keep this footer visually separate from the government content and ensure it never overlaps printable form text. If an extra informational/help page is useful, clearly mark it as a non-submission help page and state that it does not need to be submitted with the application. That page may contain user guidance, document information, photo placement, signature guidance, current authority, current fees or current rules. Any current legal, fee, authority or procedural claim must be verified only from official government sources such as an official department website, official state portal, Gazette or official government PDF. Never use random blogs as the legal source. If the original printed form contains an old fee or rule, keep the old printed wording on the original printable page and explain the current verified rule only on the separate information page. The website has an existing MySQL table named certificate_form_events. Do not CREATE, ALTER or DROP this table. Do not modify its schema. Use only prepared INSERT statements into the existing table. The expected columns are form_id, form_title, event_name, output_mode, filled_fields, total_fields, completion_percent, visitor_hash, session_hash, device_type, page_path and meta_json. Every new form must use a unique form_id slug and a correct form_title based on the current PDF. Never reuse the birth-form slug, title, analytics source or localStorage key in a different form. At minimum track the analytics events form_open, form_started, form_progress, pdf_download, print, print_dialog_open, print_dialog_close and reset. Track photo_crop only if the current form has a photo crop system. For output actions calculate output_mode as blank, partial or filled. A blank form means no meaningful user-entered field has been filled. A partial form means some meaningful fields are filled. A filled form means all countable interactive fields are filled. Automatic defaults such as today's date or a default state must not cause an untouched form to be classified as partial or filled. Send filled_fields and total_fields, and calculate completion_percent server-side as filled_fields / total_fields × 100. Never trust a client-supplied percentage as authoritative. Analytics must be privacy-safe. Never store or send actual personal form values to analytics. Never store applicant name, child name, father name, mother name, Aadhaar number, Jan Aadhaar number, mobile number, DOB, address, caste, witness names, witness mobile numbers, photos, uploaded images or any other actual form value. Store only anonymous usage metadata such as action type, completion counts, device type, page path, whether a photo exists, photo count, page count, form source, version and privacy flag. Generate a random anonymous visitor ID in localStorage and a random session ID in sessionStorage. Never store these raw IDs in MySQL. Hash them server-side using SHA-256 and a server/application secret before storing visitor_hash and session_hash. Use the existing database connection architecture. Support db(), PDO, mysqli or existing global connections such as $pdo, $mysqli, $conn, $connection or $database when available. Never hardcode new database credentials. Every analytics INSERT must use a prepared statement. Protect the analytics endpoint with CSRF. Reuse the existing csrf_token() if available or create a secure session-based fallback token. Analytics failures must never block form filling, preview, PDF or print. Use background/non-blocking fetch behavior and keepalive where useful. Do not insert a form_progress database row on every keystroke. Debounce or throttle progress tracking, for example around 500-1000ms, and avoid repeatedly saving the same completion state. Track form_open after successful page load. Track form_started once when meaningful user interaction begins. Track form_progress when the meaningful completion state changes. Track reset when the user clears the form. Store only has_photo and photo_count, never the photo itself. Set a form-specific analytics source/version in meta_json. Preserve existing SEO architecture and generate form-specific values for page title, description, keywords, focus keyword, canonical URL, Open Graph title, Open Graph description, robots, datePublished and dateModified. Use a meaningful clean URL slug based on the current form. Do not reuse SEO data from another form. Do not add DOCX/Word download functionality unless explicitly requested. Canvas may be used only for isolated image-cropping operations, never for rendering the main printable text. Before final delivery, perform a complete source-to-code review. Verify the source PDF page count, every original printable page, every critical line, every numbered section, every data-bind, every data-input, page overflow, long names, long addresses, photo placement, signatures, mobile numbers, footer overlap, Print button, PDF button, Mobile PDF button, Reset button, crop controls, persistence, analytics wiring, privacy rules, unique form ID, unique localStorage key and SEO values. Run php -l on the final PHP file and require "No syntax errors detected". Extract and validate JavaScript using node --check, including the analytics JavaScript. Verify that the certificate_form_events INSERT exists, PDF and Print events are wired, blank/partial/filled logic works at code level, personal values are not sent to analytics and analytics failure cannot break the form. Do not claim that database records are definitely being saved on the live server unless an actual hosted database test has been performed. You may state that tracking code is configured and syntax-valid. Final output must be a complete downloadable production-ready single PHP file, not a partial code snippet. Use a meaningful filename based on the current form. In the final response briefly report the source PDF page count, printable page count, extra help page count if any, PHP syntax status, JavaScript syntax status, native/vector PDF mode, analytics status, privacy status and provide the downloadable PHP file. Follow this priority order: exact original PDF wording, no missing line, preserved government/legal meaning, A4 page integrity, correct user-entered data placement, live auto-fill, native vector PDF, print, persistence, Devanagari input quality, photo/crop, analytics, privacy, responsive design, government-service UI, SEO and visual polish. Now inspect the attached ORIGINAL PDF, determine all form-specific requirements automatically, preserve the Tuvigram website architecture, recreate every government printable page as HTML/CSS Unicode A4 pages, build the dynamic form-filling panel, live preview, auto-fill, persistence, clear-form behavior, photo/crop only where required, high-quality native PDF/Print, privacy-safe certificate_form_events analytics, responsive layout and SEO, visually verify the complete form against the PDF, validate PHP and JavaScript syntax, and return one complete production-ready downloadable PHP file without asking me to repeat requirements already contained in this prompt.