DEV Community: admin@adawati.app

I got tired of bloated writing apps, so I built a Zero-Latency, Privacy-First Document Editor ⚡

admin@adawati.app — Tue, 14 Apr 2026 10:56:14 +0000

Modern writing tools are amazing, but let’s be honest: they have become incredibly bloated. Opening a simple document today often means loading megabytes of JavaScript, waiting for server syncs, and accepting that every single keystroke is being tracked and stored in a database somewhere.

Sometimes, you just need a fast, clean, and private space to write your thoughts, draft a blog post, or structure a document without the overhead.

That’s exactly why I built Adawati Docs — a lightweight, distraction-free document editor that runs directly in your browser.

You can try it live here: Adawati Docs

🛠️ The Core Philosophy: Speed and Privacy
When designing this editor, I had two strict rules:

Zero Latency: The editor must load instantly. No waiting for spinners or database connections.

Absolute Privacy: What you write is your business. The text should not be sent to any backend server for rendering or storage.

💻 Technical Highlights
To achieve this, I leaned heavily on a Client-Side First architecture. Here is how it works under the hood:

Browser as the Backend: Instead of relying on a database to save drafts, the editor leverages local storage mechanisms. Your document lives in your browser's memory. If you close the tab and come back, your work is exactly where you left it—all without a single API call.

Rich Formatting, Zero Bloat: Implementing a rich text editor that supports essential formatting (headings, lists, bolding) without turning the app into a sluggish monster was a challenge. By keeping the DOM manipulations clean and avoiding heavy third-party WYSIWYG dependencies, the typing experience remains buttery smooth.

Exporting Made Simple: Once you are done writing, you need to get your text out efficiently. The tool allows you to format your document and copy it cleanly, preserving the structure so you can paste it directly into your CMS, emails, or markdown files without weird inline CSS issues.

🌍 Fully Localized
Just like the rest of the Adawati platform, I made sure the editor handles both English (LTR) and Arabic (RTL) perfectly. Handling bi-directional text gracefully in an editor requires strict attention to CSS logical properties to ensure the cursor and text alignment don't break when switching languages.

🚀 What's Next?
Building Adawati Docs has been a great exercise in performance optimization and trusting the client's browser capabilities. My next goal is to add direct Markdown-to-PDF exporting entirely on the client-side.

I would love for you to test the editor and try writing your next post or notes on it: Adawati Docs/Editor.

What is your current go-to tool for quick, distraction-free writing? Let me know in the comments!

How I Built a 100% Client-Side, ATS-Friendly CV Builder (Zero Backend for Ultimate Privacy

admin@adawati.app — Sat, 04 Apr 2026 18:57:05 +0000

Have you ever spent an hour filling out your details on a "free" resume builder, only to be hit with a $15 paywall or a massive, ugly watermark right when you click download?

As an indie developer, I found this practice incredibly frustrating. Beyond the hidden fees, there's a massive privacy concern: why should a random server store my phone number, address, and entire employment history just to generate a PDF?

So, I decided to build my own free alternative on Adawati.app: a fast, ATS-friendly CV builder that operates 100% on the client-side. No backend storage, no hidden fees.

Here is how I approached the technical challenges.

The Core Architecture: Zero Backend The primary goal was privacy. By eliminating the backend from the PDF generation process, the user's sensitive data never leaves their browser.

Instead of sending JSON payloads to a Node.js or Python server to render a PDF using tools like Puppeteer or ReportLab, the entire heavy lifting is done in the DOM.

The ATS (Applicant Tracking System) Challenge A major trap with client-side PDF generation is taking the easy route: converting a DOM element to an HTML canvas (e.g., using html2canvas) and then putting that image into a PDF.

Why is this bad? Because ATS bots cannot read images! If your resume is just a giant image inside a PDF wrapper, you will automatically be rejected by 75% of corporate filtering systems.

The Solution:
I had to ensure the output was a true vector PDF with selectable text. Using client-side libraries that construct the PDF document programmatically ensures that the text layer is preserved. The file remains lightweight, the text is razor-sharp (no pixelation on zoom), and most importantly, an ATS can easily parse the keywords, job titles, and dates.

Handling RTL (Right-to-Left) and Localization
Since the platform targets both Arabic and English speakers, the layout had to mirror perfectly without breaking the PDF generation flow.
Switching between languages triggers a state change that not only flips the CSS (direction: rtl) for the live preview but also maps to the corresponding coordinates and text alignments in the PDF generation logic.
The Result
The final product allows users to:

Type their data and see a Live Preview.

Switch between English and Arabic seamlessly.

Download a clean, ATS-compliant PDF instantly.

You can try the live tool here: Adawati CV Builder. Turn off your Wi-Fi before clicking download if you want to test the "Client-Side only" claim! 😉

What’s Next?
Building tools that respect user privacy shouldn't be the exception; it should be the norm. My next challenge is optimizing the client-side PDF compression.

Have you worked with client-side PDF generation before? What libraries did you find most reliable for handling complex layouts and custom fonts? Let me know in the comments!

🚀 Building a High-Accuracy Arabic OCR Tool: How I Solved the "Image-to-Text" Challenge

admin@adawati.app — Thu, 26 Mar 2026 21:02:43 +0000

Extraction of text from images (OCR) is a solved problem for Latin languages, but for Arabic, it’s a whole different story. As the developer behind Adawati.app, I spent weeks engineering a solution that doesn't just "read" Arabic, but understands its complexity.

The Problem: Why Arabic OCR is Hard
Most open-source OCR engines struggle with Arabic for three reasons:

Cursive Nature: Arabic letters change shape based on their position (Start, Middle, End).

Diacritics & Dots: Small dots and marks can change the entire meaning of a word.

Low-Quality Input: Students often take photos of textbooks in poor lighting or at weird angles.

My Engineering Approach
Instead of just "plugging in" a generic API, I built a pipeline focused on Pre-processing and Contextual Inference.

Image Pre-processing (The Secret Sauce) Before the AI even looks at the image, I apply several filters:

Binarization: Converting the image to high-contrast black and white to eliminate background noise.

Deskewing: Automatically correcting the angle if the photo was taken tilted.

Noise Reduction: Removing "salt and pepper" noise often found in scanned PDFs.

The AI Engine
I utilized state-of-the-art deep learning models specifically fine-tuned for Arabic scripts. These models use CNNs (Convolutional Neural Networks) for visual feature extraction and LSTMs (Long Short-Term Memory) to understand the sequence of characters, ensuring that the connected letters are recognized as a coherent word, not just random symbols.
Privacy-First Architecture
In an era of data harvesting, I made a conscious architectural decision: Zero Retention.

Images are processed in a secure memory buffer.

Once the text is extracted, the image is purged instantly.

No databases, no logs of your documents.

Why I Built This?
I saw students struggling to transcribe their lectures and researchers stuck with non-searchable PDF archives. I wanted to provide a free, fast, and no-login tool that respects their privacy while delivering professional-grade accuracy.

Try it out
If you're a developer interested in Arabic NLP or a student looking for a reliable tool, check it out here:
👉 Image to Text - Arabic OCR Tool

I'd love to hear your feedback on the accuracy, especially with complex fonts or handwritten notes!

Arabic #OCR #AI #WebDev #Productivity #NextJS

title: Building a Free Arabic Speech-to-Text Engine using Hugging Face & Next.js

admin@adawati.app — Wed, 25 Mar 2026 13:06:10 +0000

Hello fellow developers! 👋

Handling audio processing in web applications is always tricky, but when you add Arabic dialects and academic terminology (Arabizi) to the mix, it becomes a real engineering challenge.

Recently, while building Adawati.app (an all-in-one digital workspace for Arab students), I needed to implement a reliable Speech-to-Text (STT) feature for university lectures. Paid APIs like Google Cloud or AWS were either too expensive for a free tool or struggled heavily with local Arabic dialects.

Here is how I engineered a custom, free solution using Hugging Face open-source models.

🛑 The Technical Bottlenecks

Large File Uploads & Timeouts: University lectures are often 1-2 hours long. Sending a 100MB audio file to a server in one go usually results in a 504 Gateway Timeout.
Background Noise: Lecture halls are noisy. Passing raw audio to an AI model drastically reduces transcription accuracy.
Dialect Nuances: Standard Arabic models fail when professors mix English technical terms with local Arabic dialects.

⚙️ The Architecture & Solution

To bypass these issues, I built a pipeline that processes the audio efficiently:

1. Audio Chunking (The Game Changer)
Instead of sending the whole file, I used the Web Audio API on the client-side to split the audio into smaller 30-second chunks before sending them to the backend. This prevents timeouts and allows parallel processing.

2. Pre-processing & Noise Reduction
Before hitting the AI model, the chunks go through a basic noise-reduction filter using FFmpeg to isolate human voice frequencies.

3. Hugging Face Inference
I connected the backend to a fine-tuned Whisper model hosted on Hugging Face, specifically trained on Arabic datasets.

Here is a conceptual snippet of how the chunking logic looks in the backend (Python/FastAPI wrapper):

`python
from pydub import AudioSegment
import requests

def process_large_audio(file_path):
audio = AudioSegment.from_file(file_path)
chunk_length_ms = 30000 # 30 seconds
chunks = [audio[i:i+chunk_length_ms] for i in range(0, len(audio), chunk_length_ms)]

full_transcript = ""

for idx, chunk in enumerate(chunks):
    chunk.export(f"temp_chunk_{idx}.wav", format="wav")
    # Send to Hugging Face API
    transcript = query_huggingface(f"temp_chunk_{idx}.wav")
    full_transcript += transcript + " "

return full_transcript`

🚀 The Live Result
By combining this chunking architecture with Hugging Face models, I managed to create a fast, accurate, and completely free lecture transcription tool without relying on expensive enterprise APIs.

You can test the live implementation and its accuracy with Arabic audio here:
👉 Arabic Audio-to-Text Converter - Adawati
https://adawati.app/audio-to-text/

💬 Let's Discuss!
I'm curious to know from the backend engineers here:
How do you handle massive file uploads in your Next.js/Node.js applications? Do you prefer client-side chunking or streaming directly to a cloud bucket (like AWS S3) before processing?

Let me know in the comments!

كيف قمت بحل مشكلة انعكاس الحروف العربية (RTL) عند استخراج

admin@adawati.app — Tue, 24 Mar 2026 14:01:54 +0000

`---
title: "كيف قمت بحل مشكلة انعكاس الحروف العربية (RTL) عند استخراج النصوص من ملفات PDF"
published: true

tags: webdev, pdf, arabic, programming

مرحباً أصدقائي المطورين،

أي شخص حاول التعامل مع ملفات الـ PDF برمجياً لاستخراج النصوص العربية يعرف تماماً هذا الكابوس: تسحب النص فتجده معكوساً (م ر ح ب ا)، أو تجد الحروف متقطعة وغير متصلة.

خلال عملي مؤخراً على بناء أدوات لمعالجة المستندات للطلاب، واجهت هذه المشكلة بعمق. حاولت استخدام مكتبات شهيرة مثل pdf.js أو PyPDF2، لكن النتيجة مع اللغة العربية كانت دائماً كارثية.

🔍 ما هو جذر المشكلة؟

المشكلة تكمن في أن ملفات الـ PDF لا تفهم "الكلمات" أو "الفقرات". هي ببساطة تتعامل مع المستند كـ "لوحة رسم" (Canvas)، وتقوم بوضع كل حرف في إحداثيات (X, Y) محددة. اللغات اللاتينية تُكتب من اليسار لليمين (LTR)، ومحركات الاستخراج تقرأ الإحداثيات بهذا الترتيب. أما العربية (RTL)، فيتم رسمها من اليمين لليسار، وعندما يقرأها المحرك برمجياً من اليسار لليمين، تخرج الكلمة معكوسة!

⚙️ كيف قمت بحلها؟

بدلاً من الاعتماد على القراءة النصية التقليدية للإحداثيات، قمت بدمج مكتبات إعادة التشكيل (Reshaping) وخوارزميات ثنائية الاتجاه (Bidi Algorithm) كطبقة معالجة وسيطة، بالإضافة للاستعانة بنماذج ذكاء اصطناعي عبر Hugging Face متخصصة في الـ OCR لمعالجة الحالات المستعصية.

الفكرة البرمجية المبسطة تعتمد على تمرير النص المستخرج عبر هذه الفلاتر:

`python
import arabic_reshaper
from bidi.algorithm import get_display

def fix_arabic_pdf_text(raw_text):
# 1. إعادة ربط الحروف العربية المتقطعة
reshaped_text = arabic_reshaper.reshape(raw_text)

# 2. تصحيح اتجاه القراءة من اليمين لليسار
bidi_text = get_display(reshaped_text)

return bidi_text`

🚀 النتيجة الحية (التطبيق العملي):
لتسهيل الأمر على الطلاب والزملاء، قمت بدمج هذه الخوارزمية المعقدة في واجهة ويب بسيطة ضمن منصة طورتها مؤخراً.
يمكنكم رؤية النتيجة الحية واختبار سرعة ودقة استخراج النصوص العربية (سواء من ملفات PDF أو الصور) عبر هذه الأداة المجانية:
👉 أداة استخراج النصوص (OCR) - منصة أدواتي
أتمنى أن تفيدكم هذه المقاربة في مشاريعكم القادمة. كيف تتعاملون أنتم مع ملفات الـ PDF العربية في تطبيقاتكم؟