tag:support.markedapp.com,2011-09-11:/discussions/problems/112097-script-generated-at-html-exportMarked: Discussion 2017-12-29T19:12:40Ztag:support.markedapp.com,2011-09-11:Comment/396130502016-04-11T14:47:34Z2016-04-11T14:47:34Zscript generated at html export<div><p>This is the javascript that determines whether a paragraph or
headline<br>
is in Arabic or other RTL format. I currently have it embedded
by<br>
default as it's an automatic feature of the preview (only included
if<br>
the style is also embedded based on save dialog settings). Are
you<br>
finding the output problematic?</p></div>Bretttag:support.markedapp.com,2011-09-11:Comment/396130502016-04-11T14:50:34Z2016-04-11T14:50:34Zscript generated at html export<div><p>I just realized I did add an option to disable this feature.
Under<br>
Preferences->Style->Layout and Typography, you can disable
"Detect and<br>
style RTL text" to remove the script.</p>
<p>-Brett</p></div>Bretttag:support.markedapp.com,2011-09-11:Comment/396130502016-04-11T20:53:27Z2016-04-11T20:53:27Zscript generated at html export<div><p>Weird, that option is not enabled on my install. I tried to
enable it, exported to html, the script is there. Disabled the
option, script is there, too.</p>
<p>It's not problematic per se, but I export my articles to html
for clients and I don't want any unnecessary code in there that
might throw them off and give me complaints.</p></div>godzillatetag:support.markedapp.com,2011-09-11:Comment/396130502016-04-12T15:05:59Z2016-04-12T15:05:59Zscript generated at html export<div><p>Ok, I'll take a look at why it's not excluding that script when
the<br>
option is disabled. Can I ask why you share the HTML version and
not a<br>
PDF with clients?</p>
<p>-Brett</p></div>Bretttag:support.markedapp.com,2011-09-11:Comment/396130502016-04-12T18:56:43Z2016-04-12T18:56:43Zscript generated at html export<div><p>Sure, I write my articles in Markdown and export to HTML because
it's easy to just copy and paste the code into a CMS. In a perfect
world I'd just give them the Markdown files and they would export
to whatever they like. Sadly, we are not there yet.</p></div>godzillatetag:support.markedapp.com,2011-09-11:Comment/396130502016-04-12T19:03:47Z2016-04-12T19:03:47Zscript generated at html export<div><p>If you export without the style embedded, you should get
something much easier to embed in other platforms (sans styling,
style sheets, and scripts).</p>
<p>-Brett</p></div>Bretttag:support.markedapp.com,2011-09-11:Comment/396130502016-04-14T10:43:53Z2016-04-14T10:43:53Zscript generated at html export<div><p>I know, the problem is that I have to use a style because I work
with a marketing agency that uses it's own branding. All the
exported documents have the same style.</p></div>godzillatetag:support.markedapp.com,2011-09-11:Comment/396130502017-12-28T00:34:39Z2017-12-28T00:34:40Zscript generated at html export<div><p>I believe that there is currently a bug in Marked 2 (2.5.10 930) with disabling this RTL detect feature.</p>
<p>I have a preprocessor that injects "class='rtl'" html elements, and an attached custom css stylesheet that styles them with direction:rtl. On opening a document in Marked 2 with my preprocessor enabled and the "Preferences > Style > Detect and style RTL text" unchecked, strange things happen -- for example, nested rtl > ltr elements cannot override direction by any method (!important, etc.). Using inspect and attempting to style elements directly in the DOM likewise has no effect -- it appears to be overridden by Javascript, even though the preference is unchecked.</p>
<p>When I turn <em>on</em> the detect checkbox on an open document, it produces no visual change -- nested ltr elements are still being forced rtl. When I then turn the checkbox <em>off</em> again, it seems to strips all 'rtl' class information from the document -- including all of my 'rtl' class tags that were originally injected by my preprocessor. Whether the option is on or off, my document is incorrect when compared to a web preview.</p>
<p>I would love a setting where the Marked 2 RTL-detector can be just completely disabled -- or advice on a workaround. For a temporary workaround I have changed the name of my pre-processor class from 'rtl' to something else -- this seems to prevent Marked 2 from interfering with it -- but that isn't a good long-term solution.</p></div>Jeremy Douglasstag:support.markedapp.com,2011-09-11:Comment/396130502017-12-28T20:58:25Z2017-12-28T20:58:25Zscript generated at html export<div><p>This is because of a workaround I had to do at one point, as a result<br>
the only difference when exporting without RTL detection is that it<br>
doesn't actually style the RTL, but still applies the classes. Using a<br>
different name in your script is ideal, but I'd consider changing the<br>
class that Marked applies to something more namespaced (eg mk-rtl) to<br>
avoid conflicts. I'll also take a look at disabling the script on export<br>
properly.</p>
<p>-Brett</p></div>Bretttag:support.markedapp.com,2011-09-11:Comment/396130502017-12-29T19:12:39Z2017-12-29T19:12:40Zscript generated at html export<div><p>Thank you su much, Brett -- namespacing "mk-rtl" would be a perfect fix.</p>
<p>I'd love to be able to pass toolchains that use <code>class='rtl'</code> through Marked 2 unchanged.</p></div>Jeremy Douglass